[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                          A. Cooper
Internet-Draft                                                       CDT
Intended status: Informational                             H. Tschofenig
Expires: June 3, 2013                             Nokia Siemens Networks
                                                             J. Peterson
                                                                 NeuStar
                                                                B. Aboba
                                                               Microsoft
                                                       November 30, 2012


                   Secure Call Origin Identification
                 draft-cooper-iab-secure-origin-00.txt

Abstract

   A number of parties have suggested creating mandates such that
   networks receiving voice calls would be capable of securely
   identifying the call origin.  This document provides insights about
   the capabilities and limitations of supporting call origin
   identification in a secure and privacy- friendly way in the PSTN and
   for IP-based real-time communications.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on June 3, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of



Cooper, et al.            Expires June 3, 2013                  [Page 1]

Internet-Draft                Secure Origin                November 2012


   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Secure Origin Challenges in the PSTN  . . . . . . . . . . . . . 3
   3.  Secure Origin Challenges for VoIP . . . . . . . . . . . . . . . 4
   4.  Secure Origin Challenges for Real-Time Communication on
       the Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   7.  Informative References  . . . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7
































Cooper, et al.            Expires June 3, 2013                  [Page 2]

Internet-Draft                Secure Origin                November 2012


1.  Introduction

   A number of parties have suggested creating mandates such that
   networks receiving voice calls would be capable of securely
   identifying the call origin [TD-62].  These proposals are primarily
   motivated by concerns over fraudulent calls and the associated
   economic impact that spoofed or fraudulent origin identification can
   have on telecommunications settlement agreements.  Concerns have also
   been raised about ensuring secure origin identification for law
   enforcement and abuse tracking purposes.

   Support for caller identification in the public switched telephone
   network (PSTN) has been developed to meet existing regulatory needs
   and for other purposes, but it has limitations.  As real-time
   communication has become IP-based, it has become significantly more
   difficult to identify the origin of real-time communication for a
   number of reasons.  Furthermore, to the extent that new mandates are
   being suggested to require origin identification for all IP traffic
   -- real-time or not -- it is unclear how such identification would be
   accomplished given the complexity and diversity of today's IP network
   traffic.  This document provides insights about the capabilities and
   limitations of supporting call origin identification in a secure and
   privacy-friendly way in the PSTN and for IP-based real-time
   communications.


2.  Secure Origin Challenges in the PSTN

   The problems facing origin identification are not limited to the
   Internet.  In the traditional public switched telephone network,
   information about the calling party is often missing from signaling
   messages.  This is because, per the ITU-T and related national
   specifications (beginning with Q.761), the calling party number field
   of a call establishment message (IAM) is an optional parameter.
   There remain a number of legitimate reasons today why the origin of a
   telephone call might be absent from call establishment signaling:
   because of interworking with a legacy (pre-SS7) network or a private
   branch exchange which lacks the capability to identify subscribers,
   for example, or because the call has been handled by an interexchange
   carrier using calling cards that require the customer to dial a relay
   number.  So long as there are legitimate reasons why the calling
   party number might be missing from a call, and the parameter remains
   optional in the SS7 standards, carriers will sometimes fail to
   provide origin identification in the telephone network.  Parties who
   want to obscure their identity can rely on equipment or carriers that
   do not provide the calling party number.

   Whether or not the calling party number should be trusted, if it is



Cooper, et al.            Expires June 3, 2013                  [Page 3]

Internet-Draft                Secure Origin                November 2012


   present, is a separate but related question.  Private branch
   exchanges that signal calls via ISDN (Q.931) can provide an arbitrary
   calling party number in their own call establishment message (SETUP),
   and some operators translate those numbers directly to the calling
   party number field of SS7.  Due to the transitive trust inherent in
   the SS7 network, there is no way for the recipient of a call to
   determine how trustworthy the calling party number field is:
   effectively, all carriers in the telephone network necessarily trust
   the origin identification provided by any carrier.  These
   difficulties have been exacerbated by the widespread deployment of
   Internet gateways.  For these gateways, it is almost always better to
   supply no calling party number to the SS7 network than it is to
   accept a number provided by Internet signaling.  Because some
   gateways do accept the numbers provided by Internet callers, however,
   this further weakens the trustworthiness of calling party number
   information on the telephone network.  These concerns are not limited
   to calls either: text messages have similar problems resulting from
   email-to-text gateways.

   Our ability to solve origin identification for Internet calling
   depends on solving it for the telephone network, as Internet
   telephony solutions inevitably exchange traffic with the telephone
   network.  Given the inherent limitations of SS7 standards for origin
   identification, the transitive trust properties of the telephone
   network, and the widespread acceptance of calls without origin
   identification in the telephone system today, the prospects are very
   doubtful for remedying this problem by simply mandating that carriers
   provide origin identification.


3.  Secure Origin Challenges for VoIP

   Standards for Voice Over IP (VoIP) originally focused on Session
   Initiation Protocol (SIP) and Extensible Messaging and Presence
   Protocol (XMPP)-based systems, with SIP becoming a popular foundation
   for many proprietary VoIP systems.  SIP provides a number of
   different mechanisms for asserting the identity of a caller,
   including "P-Asserted-Identity" (PAI) [RFC3325], "SIP Cert" [RFC6072]
   and the "SIP Identity" mechanism [RFC4474].  PAI and SIP Identity
   allow SIP application servers in the network to insert caller
   information into the 'From' header of outgoing calls.

   However, not all calls will necessarily identify the calling party in
   any way, and there are no standardized requirements to use any
   particular caller identification solution.  Anonymous calls and calls
   made from outbound-only calling services generally do not contain
   identity information.  In addition, in some situations, calls made
   through relay services may identify the relay as the calling party



Cooper, et al.            Expires June 3, 2013                  [Page 4]

Internet-Draft                Secure Origin                November 2012


   rather than the original caller.

   In addition, the identifier syntax used in SIP varies from email-
   address-style identifiers to ones that use E.164 telephone numbers.
   Because of the security shortcomings of the PSTN described above,
   SIP-based services that seek to make authentication and
   identification guarantees cannot do so purely with E.164 numbers.
   Such guarantees would require a universal move toward email-style
   identifiers.

   Even in a SIP-only environment, the choice of syntax, made separately
   by different implementers and users, impacts the security mechanisms
   that can be used for attesting to the authenticity of the identifier.
   Without any form of cryptographic identity assertion, the 'From'
   header can be easily forged, and headers are often stripped or
   modified by intermediaries in transit.  Attempts at enhancing the
   integrity protection of SIP identity have not seen wide deployment.

   Finally, SIP supports a number of privacy mechanisms that allow SIP
   users to shield their identities from the network and the called
   party [RFC3323] [RFC5767] [RFC5379].  SIP privacy has valid uses; for
   example, it enables users to avoid exposing their identity to
   destinations that might make them a target for unsolicited
   advertising or other undesirable consequences.  As in the PSTN,
   parties that do not wish to disclose their identities can use
   services that support this functionality.


4.  Secure Origin Challenges for Real-Time Communication on the Web

   While SIP and XMPP were originally designed to facilitate
   interoperable real-time communications between systems developed by
   different vendors, the last 10 years have seen the rise of a new
   platform for deployment of applications: the world wide web.  Web
   applications that run in a secure execution environment inside a web
   browser are now commonplace.  As a result, real-time communications
   -- including voice and video telephony -- are migrating to the web as
   well.

   This new trend in application development enables real-time
   application to be downloaded on-demand and executed within the
   browser utilizing new interfaces in the browser platform to interact
   with the microphone, camera, and other sensors.  The integration of
   real-time communication into the huge web ecosystem opens a number of
   new possibilities that were previously only possible with proprietary
   browser plug-ins.

   This migration to the web does not eliminate the challenges



Cooper, et al.            Expires June 3, 2013                  [Page 5]

Internet-Draft                Secure Origin                November 2012


   associated with providing secure call origin identification; in some
   ways, it even serves to complicate the situation.  While web servers
   have a common and widely used means of authenticating themselves --
   public key-based authentication infrastructure for use with SSL -- no
   single client-side authentication mechanism has emerged to
   authenticate users sitting in front of their browsers.  Instead, a
   variety of technologies have been deployed, often with applicability
   only in narrow sectors.

   Enterprise networks, for example, often use hardware tokens to
   authenticate employees.  Banking web sites often require one-time
   secrets in combination with knowledge-based security.  Many consumer-
   focused web sites tend to rely on insecure password-based
   authentication.  With so many web sites requiring authentication, Web
   Single-Sign-On (WebSSO) deployments have emerged to attempt to create
   a uniform authentication mechanism.  But while individual identity
   providers offering such WebSSO solutions offer security benefits and
   great convenience for end users, they too are typically limited as
   far as the scope of web sites that can rely on them for
   authentication.  Relying web sites, likewise, usually only support a
   single or limited set of identity providers.  Consequently, users are
   confronted with islands on the web that use different identity
   technologies.

   Because web-based real-time applications extends the existing web
   ecosystem, they also inherit its identity management ecosystem, a
   system that is still in flux.  With new technology being developed
   every day it is unlikely that a single identity management technology
   will dominate in the near future.  Furthermore, because of the
   technological differences between web identity management and caller
   identification in SIP and other previously developed real-time
   communication technologies, the seamless flow of identity information
   across these technologies will likely remain elusive for the
   foreseeable future.


5.  Conclusion

   Every calling technology presents significant challenges to the
   secure identification of the caller.  The interoperation of all of
   these technologies -- from legacy pre-SS7 telephone networks to
   cutting edge web-based calling services -- further complicates the
   task of identifying the origin of a call in a trusted and
   interoperable way.  While industry efforts are underway to address
   some of these challenges, a uniform origin identification system is
   unlikely to emerge, regardless of potential regulatory mandates.





Cooper, et al.            Expires June 3, 2013                  [Page 6]

Internet-Draft                Secure Origin                November 2012


6.  Security Considerations

   This document describes, at a high level, some of the security
   challenges of providing trustworthy call origin information.  There
   are further detailed privacy and security aspects related to call
   origin identification that will be addressed in a future version of
   this document.


7.  Informative References

   [RFC3323]  Peterson, J., "A Privacy Mechanism for the Session
              Initiation Protocol (SIP)", RFC 3323, November 2002.

   [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.

   [RFC5379]  Munakata, M., Schubert, S., and T. Ohba, "Guidelines for
              Using the Privacy Mechanism for SIP", RFC 5379,
              February 2010.

   [RFC5767]  Munakata, M., Schubert, S., and T. Ohba, "User-Agent-
              Driven Privacy Mechanism for SIP", RFC 5767, April 2010.

   [RFC6072]  Jennings, C. and J. Fischl, "Certificate Management
              Service for the Session Initiation Protocol (SIP)",
              RFC 6072, February 2011.

   [TD-62]    Council Working Group to Prepare for the 2012 World
              Conference on International Telecommunications, "CWG-
              WCIT12 Temporary Document 62 Rev.2 - Draft Compilation of
              Proposals with Options for Revisions to the ITRs", 2012, <
              http://files.wcitleaks.org/public/
              T09-CWG.WCIT12-120620-TD-PLEN-0062R2.pdf>.











Cooper, et al.            Expires June 3, 2013                  [Page 7]

Internet-Draft                Secure Origin                November 2012


Authors' Addresses

   Alissa Cooper
   CDT
   1634 Eye St. NW, Suite 1100
   Washington, DC  20006
   USA

   Email: acooper@cdt.org


   Hannes Tschofenig
   Nokia Siemens Networks

   Email: hannes.tschofenig@gmx.net


   Jon Peterson
   NeuStar

   Email: jon.peterson@neustar.biz


   Bernard Aboba
   Microsoft

   Email: bernard.aboba@gmail.com
























Cooper, et al.            Expires June 3, 2013                  [Page 8]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/