<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl'
href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "http://xml.resource.org/authoring/rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC3325 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3325.xml">
<!ENTITY RFC4474 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4474.xml">
<!ENTITY I-D.elwell-sip-e2e-identity-important SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.elwell-sip-e2e-identity-important.xml">
<!ENTITY I-D.kaplan-sip-uris-change SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.kaplan-sip-uris-change.xml">
<!ENTITY I-D.elwell-sip-identity-handling-ua SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.elwell-sip-identity-handling-ua.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info"
docName="draft-york-sip-visual-identifier-trusted-identity-01" ipr="full3978">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<title abbrev="Visual Identifier of Trusted Identity">The
Importance of a Visual Identifier of Trusted Identity</title>
<author fullname="Dan York" initials="D." surname="York">
<organization abbrev="Voxeo">Voxeo Corporation</organization>
<address>
<postal>
<street></street>
<city>Keene</city>
<region>NH</region>
<code></code>
<country>USA</country>
</postal>
<phone>+1-407-455-5859</phone>
<email>dyork@voxeo.com</email>
<uri>http://www.voxeo.com/</uri>
</address>
</author>
<date year="2008" />
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>SIP</workgroup>
<keyword>identity</keyword>
<abstract>
<t>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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>As discussed at some length on the SIP and SIPPING mailing lists and recently
summarized by John Elwell in <xref target="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.</t>
<t>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.</t>
<t>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 <xref
target="RFC3325">P-Asserted-Identity</xref> headers. This
modification could occur conceivably at any point in the chain of
transmission between the SIP source and destination. SIP Identity
defined in <xref target="RFC4474"/> attempts to address this issue
but for reasons outlined in both <xref
target="I-D.elwell-sip-e2e-identity-important"/> and <xref
target="I-D.kaplan-sip-uris-change"/> this mechanism often fails.
</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="AuthorsNote" title="Author's Note">
<t>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.</t>
<t>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?</t>
<t>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.</t>
<t>Note also that John Elwell has recently (Oct 2008) come out
with a new draft, <xref
target="I-D.elwell-sip-identity-handling-ua"/>, that summarizes
the overall issues and incorporates many of the ideas/issues
raised here.</t>
</section>
<section anchor="Recommendation" title="Recommendation">
<t>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".</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="States" title="Visual Identifier States">
<t>In the review of the initial version of this document, it was
identified that there are really three different states this
identifier could have:
<list style="symbols">
<t>TRUSTED - The identity of the caller can be securely
identified from the initiating SIP endpoint.</t>
<t>UNTRUSTED - The identity of the caller can NOT be securely
identified.</t>
<t>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.</t>
</list></t>
<t>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?</t>
</section>
<section anchor="Challenges" title="Challenges">
<t>There are a number of challenges to both the development
and deployment of such a visual identifier.</t>
<section anchor="Non-visual" title="Non-visual Endpoints">
<t>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.</t>
<t>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.</t>
</section>
<section anchor="ManyVendors" title="Many Vendors">
<t>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.</t>
</section>
<section anchor="LimitedDisplays" title="Limited Display Size">
<t>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.</t>
</section>
<section anchor="Fonts" title="Fonts">
<t>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.</t>
<t>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. </t>
</section>
<section anchor="Multiple Callers" title="Multiple Callers">
<t>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.</t>
</section>
<section anchor="TrustedVsSecure" title="Trusted Identity does not
mean a 'secure call'">
<t>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.]</t>
<t>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.</t>
</section>
<section anchor="SingleIdentifier" title="Single Security Visual Identifier">
<t>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 room for a single identifier.</t>
<t>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.</t>
</section>
</section>
<section anchor="Conclusions" title="Conclusions">
<t>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.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document requires no IANA actions.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>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.</t>
<t>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.</t>
</section>
<section anchor="acknowledgements" title="Acknowledgements">
<t>The author acknowledges that the decision to create this draft was
made after reading a posting to the SIP mailing list by Paul Kyzivat.</t>
<t>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.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Informative References">
&I-D.elwell-sip-e2e-identity-important;
&I-D.elwell-sip-identity-handling-ua;
&I-D.kaplan-sip-uris-change;
&RFC4474;
&RFC3325;
</references>
</back>
</rfc>
