Internet DRAFT - draft-york-sip-visual-identifier-trusted-identity
draft-york-sip-visual-identifier-trusted-identity
SIP D. York
Internet-Draft Voxeo
Intended status: Informational November 3, 2008
Expires: May 7, 2009
The Importance of a Visual Identifier of Trusted Identity
draft-york-sip-visual-identifier-trusted-identity-01
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 May 7, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
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.
York Expires May 7, 2009 [Page 1]
Internet-Draft Visual Identifier of Trusted Identity November 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Visual Identifier States . . . . . . . . . . . . . . . . . . . 5
5. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Non-visual Endpoints . . . . . . . . . . . . . . . . . . . 5
5.2. Many Vendors . . . . . . . . . . . . . . . . . . . . . . . 6
5.3. Limited Display Size . . . . . . . . . . . . . . . . . . . 6
5.4. Fonts . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.5. Multiple Callers . . . . . . . . . . . . . . . . . . . . . 6
5.6. Trusted Identity does not mean a 'secure call' . . . . . . 7
5.7. Single Security Visual Identifier . . . . . . . . . . . . 7
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
10. Informative References . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 11
York Expires May 7, 2009 [Page 2]
Internet-Draft Visual Identifier of Trusted Identity November 2008
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] 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 [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] attempts to address this issue but for reasons
outlined in both [I-D.elwell-sip-e2e-identity-important] and
[I-D.kaplan-sip-uris-change] 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.
York Expires May 7, 2009 [Page 3]
Internet-Draft Visual Identifier of Trusted Identity November 2008
2. Author's Note
As this deals with the "user interface" presented to the end user, it
is not at all clear that 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?
Regardless of whether or not this document proceeds as IETF work, the
point is that discussions around protocols and systems developed
within the IETF for establishing trusted identity should take into
account the fact that such a visual identifier may be desired by end
users and implemented by vendors. Work done within the IETF should
not preclude the development of such a visual identifier.
Note also that John Elwell has recently (Oct 2008) come out with a
new draft, [I-D.elwell-sip-identity-handling-ua], that summarizes the
overall issues and incorporates many of the ideas/issues raised here.
3. 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.
York Expires May 7, 2009 [Page 4]
Internet-Draft Visual Identifier of Trusted Identity November 2008
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. Different colors could be
used, but not all displays may allow the display of colors. Should
this work move forward, more investigation needs to be done into what
is the appropriate form of the visual identifier.
4. Visual Identifier States
In the review of the initial version of this document, it was
identified that there are really three different states this
identifier could have:
o TRUSTED - The identity of the caller can be securely identified
from the initiating SIP endpoint.
o UNTRUSTED - The identity of the caller can NOT be securely
identified.
o TRUSTED FROM THE PSTN GATEWAY - The identity of the caller can be
securely identified from a PSTN-to-SIP gateway to the recipient's
SIP endpoint, but because the call originated on the PSTN, there
can be no guarantee that the identity of the PSTN number can be
trusted.
There was a good discussion about whether this third case of PSTN
interconnectivity merited an actual display status. All agreed that
while we could not trust the identity of the PSTN Caller ID, we could
securely assert the identity of the PSTN gateway. Is there value in
passing this information along to the end user? If we eliminated the
third case and simply treated all calls from the PSTN as "untrusted"
would this distress end users? Or is that the appropriate path to
take?
5. Challenges
There are a number of challenges to both the development and
deployment of such a visual identifier.
5.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
York Expires May 7, 2009 [Page 5]
Internet-Draft Visual Identifier of Trusted Identity November 2008
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.
5.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.
5.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.
5.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.
5.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
York Expires May 7, 2009 [Page 6]
Internet-Draft Visual Identifier of Trusted Identity November 2008
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.
5.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.
5.7. Single Security Visual Identifier
In the review of the initial version of this document, there was
discussion around whether there should be a *single* visual
identifier that includes both the "secure media" status and the
"trusted identity". The argument was made that users are going to
want to know both, may not care about the difference and may only
want to see one visual identifier. The argument was also made that
in some user interfaces there may be limited display space and only
York Expires May 7, 2009 [Page 7]
Internet-Draft Visual Identifier of Trusted Identity November 2008
room for a single identifier.
The counter-argument is that given the reality of the small amount of
deployed secure media it will be far easier to provide people with a
designation of "trusted identity" than it will be to provide a
designation of both. Waiting for deployment of "secure media" would
significantly delay the availability of "trusted identity"
information which could be used far sooner.
6. 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.
7. IANA Considerations
This document requires no IANA actions.
8. 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.
York Expires May 7, 2009 [Page 8]
Internet-Draft Visual Identifier of Trusted Identity November 2008
9. 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.
The author thanks the following people for their review of the
initial draft and participation in discussion: Vijay Gurbani, John
Elwell, Paul Kyzivat, Spencer Dawkins, David Oran and Adam Roach.
10. Informative References
[I-D.elwell-sip-e2e-identity-important]
Elwell, J., "End-to-End Identity Important in the Session
Initiation Protocol (SIP)",
draft-elwell-sip-e2e-identity-important-01 (work in
progress), October 2008.
[I-D.elwell-sip-identity-handling-ua]
Elwell, J., "Identity Handling at a Session Initiation
Protocol (SIP) User Agent",
draft-elwell-sip-identity-handling-ua-00 (work in
progress), October 2008.
[I-D.kaplan-sip-uris-change]
Kaplan, H., "Why URIs Are Changed Crossing Domains",
draft-kaplan-sip-uris-change-00 (work in progress),
February 2008.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
November 2002.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
York Expires May 7, 2009 [Page 9]
Internet-Draft Visual Identifier of Trusted Identity November 2008
Author's Address
Dan York
Voxeo Corporation
Keene, NH
USA
Phone: +1-407-455-5859
Email: dyork@voxeo.com
URI: http://www.voxeo.com/
York Expires May 7, 2009 [Page 10]
Internet-Draft Visual Identifier of Trusted Identity November 2008
Full Copyright Statement
Copyright (C) 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
York Expires May 7, 2009 [Page 11]
