[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                        E. Rescorla
Internet-Draft                                                   Mozilla
Intended status: Standards Track                             J. Peterson
Expires: May 4, 2017                                             Neustar
                                                        October 31, 2016


              STIR Out of Band Architecture and Use Cases
                  draft-rescorla-stir-fallback-01.txt

Abstract

   Existing work has defined ways to secure the identity of SIP calls,
   but the in-band mechanisms defined in that work do not properly
   transit the PSTN.  This document defines out-of-band mechanisms which
   do not require modifying the messages that pass over the PSTN.

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 May 4, 2017.

Copyright Notice

   Copyright (c) 2016 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
   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.



Rescorla & Peterson        Expires May 4, 2017                  [Page 1]


Internet-Draft                STIR Fallback                 October 2016


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Operating Environments  . . . . . . . . . . . . . . . . . . .   4
   4.  Dataflows . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Case 1: VoIP to PSTN Call . . . . . . . . . . . . . . . .   6
     5.2.  Case 2: Two Smart PSTN endpoints  . . . . . . . . . . . .   6
     5.3.  Case 3: PSTN to VoIP Call . . . . . . . . . . . . . . . .   6
     5.4.  Case 4: Gateway Out-of-band . . . . . . . . . . . . . . .   7
   6.  Solution Architecture . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Credentials and Phone Numbers . . . . . . . . . . . . . .   7
     6.2.  Solution Architecture . . . . . . . . . . . . . . . . . .   8
     6.3.  Security Analysis . . . . . . . . . . . . . . . . . . . .   9
     6.4.  Substitution Attacks  . . . . . . . . . . . . . . . . . .   9
   7.  Call Placement Service Discovery and Interface  . . . . . . .  10
   8.  Some Potential Enhancements . . . . . . . . . . . . . . . . .  11
     8.1.  Encrypted PASSporTs . . . . . . . . . . . . . . . . . . .  11
       8.1.1.  Credential Lookup . . . . . . . . . . . . . . . . . .  12
     8.2.  Federated Call Placement Services . . . . . . . . . . . .  12
     8.3.  Escalation to VoIP  . . . . . . . . . . . . . . . . . . .  13
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  13
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  13
   12. Informative References  . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   The STIR problem statement [RFC7340] describes widespread problems
   enabled by impersonation in the telephone network, including illegal
   robocalling, voicemail hacking, and swatting.  As telephone services
   are increasingly migrating onto the Internet, and using Voice over IP
   (VoIP) protocols such as SIP [RFC3261], it is necessary for these
   protocols to support stronger identity mechanisms to prevent
   impersonation.  For example, [I-D.ietf-stir-rfc4474bis] defines an
   Identity header of SIP requests capable of carrying a PASSporT
   [I-D.ietf-stir-passport] object in SIP as a means to
   cryptographically attest that the originator of a telephone call is
   authorized to use the calling party number (or, for native SIP cases,
   SIP URI) associated with the originator of the call.  of the request.

   Not all telephone calls use SIP today, however; and even those that
   do use SIP do not always carry SIP signaling end-to-end.  Most calls
   from telephone numbers still traverse the Public Switched Telephone
   Network (PSTN) at some point.  Broadly, calls fall into one of three
   categories:



Rescorla & Peterson        Expires May 4, 2017                  [Page 2]


Internet-Draft                STIR Fallback                 October 2016


   1.  One or both of the endpoints is actually a PSTN endpoint.

   2.  Both of the endpoints are non-PSTN (SIP, Jingle, ...) but the
       call transits the PSTN at some point.

   3.  Non-PSTN calls which do not transit the PSTN at all (such as
       native SIP end-to-end calls).

   The first two categories represent the majority of telephone calls
   associated with problems like illegal robocalling: many robocalls
   today originate on the Internet but terminate at PSTN endpoints.
   However, the core network elements that operate the PSTN are legacy
   devices that are unlikely to be upgradable at this point to support
   an in-band authentication system.  As such, those devices largely
   cannot be modified to pass signatures originating on the Internet--or
   indeed any inband signaling data--intact.  In some cases they will
   strip the signatures from PSTN signaling; in others, they might
   damage them to the point where they cannot be verified.  For those
   first two categories above, any in-band authentication scheme does
   not seem practical in the current environment.

   But while the core network of the PSTN remains fixed, the endpoints
   of the telephone network are becoming increasingly programmable and
   sophisticated.  Landline "plain old telephone service" deployments,
   especially in the developed world, are shrinking, and increasingly
   being replaced by three classes of intelligent devices: smart phones,
   IP PBXs, and terminal adapters.  All three are general purpose
   computers, and typically all three have Internet access as well as
   access to the PSTN.  This provides a potential avenue for building an
   authentication system that changes only the endpoints while leaving
   the PSTN intact.

   This specification therefore builds on the PASSporT
   [I-D.ietf-stir-passport] mechanism and the work of
   [I-D.ietf-stir-rfc4474bis] to define a way that a PASSporT object
   created in the originating network of the call can reach the
   terminating network even when it cannot be carried end-to-end in-band
   in the call signaling.  This relies on a new service defined in this
   document that permits the PASSporT object to be stored during call
   processing and retrieved for verification purposes.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [RFC2119].




Rescorla & Peterson        Expires May 4, 2017                  [Page 3]


Internet-Draft                STIR Fallback                 October 2016


3.  Operating Environments

   This section describes the environment in which the proposed
   mechanism is intended to operate.  In the simplest setting, Alice is
   calling Bob through some set of gateways and/or the PSTN.  Both Alice
   and Bob have smart devices which can be modified, but they do not
   have a clear connection between them: Alice cannot inject any data
   into signaling which Bob can read, with the exception of the asserted
   destination and origination E.164 numbers.  The calling party number
   might originate from her own device or from the network.  These
   numbers are effectively the only data that can be used for
   coordination between the endpoints.

                                 +---------+
                                /           \
                            +---             +---+
       +----------+        /                      \        +----------+
       |          |       |        Gateways        |       |          |
       |   Alice  |<----->|         and/or         |<----->|    Bob   |
       | (caller) |       |          PSTN          |       | (callee) |
       +----------+        \                      /        +----------+
                            +---             +---+
                                \           /
                                 +---------+

   In a more complicated setting, Alice and/or Bob may not have a smart
   or programmable device, but one or both of them are behind a STIR-
   aware gateway that can participate in out-of-band coordination, as
   shown below:

                                 +---------+
                                /           \
                            +---             +---+
      +----------+  +--+   /                      \   +--+  +----------+
      |          |  |  |  |        Gateways        |  |  |  |          |
      |   Alice  |<-|GW|->|         and/or         |<-|GW|->|    Bob   |
      | (caller) |  |  |  |          PSTN          |  |  |  | (callee) |
      +----------+  +--+   \                      /   +--+  +----------+
                            +---             +---+
                                \           /
                                 +---------+

   In such a case, Alice might have an analog connection to her gateway/
   switch which is responsible for her identity.  Similarly, the gateway
   would verify Alice's identity, generate the right calling party
   number information and provide that number to Bob using ordinary POTS
   mechanisms.




Rescorla & Peterson        Expires May 4, 2017                  [Page 4]


Internet-Draft                STIR Fallback                 October 2016


4.  Dataflows

   Because in these operating environments endpoints cannot pass
   cryptographic information to one another directly through signaling,
   any solution must involve some rendezvous mechanism to allow
   endpoints to communicate.  We call this rendezvous service a "call
   placement service" (CPS), a service where a record of call placement,
   in this case a PASSporT, can be stored for future retrieval.  In
   principle this service could communicate any information, but
   minimally we expect it to include a full-form PASSporT that attests
   the caller, callee, and the time of the call.  The callee can use the
   existence of a PASSporT for a given incoming call as rough validation
   of the asserted origin of that call.  (See Section 8.1.1 for
   limitations of this design.)

   There are roughly two plausible dataflow architectures for the CPS:

      The callee registers with the CPS.  When the caller wishes to
      place a call to the callee, it sends the PASSporT to the CPS which
      forwards it to the callee.

      The caller stores the PASSporT with the CPS at the time of call
      placement.  When the callee receives the call, it contacts the CPS
      and retrieves the CDR.

   While the first architecture is roughly isomorphic to current VoIP
   protocols, it shares their drawbacks.  Specifically, the callee must
   maintain a full-time connection to the CPS to serve as a notification
   channel.  This comes with the usual networking costs to the callee
   and is especially problematic for mobile endpoints.  Thus, we focus
   on the second architecture in which the PSTN incoming call serves as
   the notification channel and the callee can then contact the CPS to
   retrieve the PASSporT.

5.  Use Cases

   The following are the motivating use cases for this mechanism.  Bear
   in mind that just as in [I-D.ietf-stir-rfc4474bis] there may be
   multiple Identity headers in a single SIP INVITE, so there may be
   multiple PASSporTs in this out-of-band mechanism associated with a
   single call.  For example, a SIP user agent might create a PASSporT
   for a call with an end user credential, and as the call exits the
   originating administrative domain the network authentication service
   might create its own PASSporT for the same call.  As such, these use
   cases may overlap in the processing of a single call.






Rescorla & Peterson        Expires May 4, 2017                  [Page 5]


Internet-Draft                STIR Fallback                 October 2016


5.1.  Case 1: VoIP to PSTN Call

   A call originates in the SIP world in a STIR-aware administrative
   domain.  The local authentication service for that administrative
   domain creates a PASSporT which is carried in band in the call per
   [I-D.ietf-stir-rfc4474bis].  The call is routed out of the
   originating administrative domain and eventually reaches a gateway to
   the PSTN.  Eventually, the call will terminate on a mobile smartphone
   that supports this out-of-band mechanism.

   In this use case, the originating authentication service can store
   the PASSporT with the appropriate CPS for the target telephone number
   as a fallback in case SIP signaling will not reach end-to-end.  When
   the destination mobile smartphone receives the call over the PSTN, it
   consults the CPS and discovers a PASSporT from the originating
   telephone number waiting for it.  It uses this PASSporT to verify the
   calling party number.

5.2.  Case 2: Two Smart PSTN endpoints

   A call originates with an enterprise PBX that has both Internet
   access and a built-in gateway to the PSTN.  It will immediately drop
   its call to the PSTN, but before it does, it provisions a PASSporT on
   the CPS associated with the target telephone number.

   After normal PSTN routing, the call lands on a smart mobile handset
   that supports the STIR out-of-band mechanism.  It queries the
   appropriate CPS over the Internet to determine if a call has been
   placed to it by a STIR-aware device.  It finds the PASSporT
   provisioned by the enterprise PBX and uses it to verify the calling
   party number.

5.3.  Case 3: PSTN to VoIP Call

   A call originates with an enterprise PBX that has both Internet
   access and a built-in gateway to the PSTN.  It will immediate drop
   the call to the PSTN, but before it does, it provisions a PASSporT
   with the CPS associated with the target telephone number.  However,
   it turns out that the call will eventually route through the PSTN to
   an Internet gateway, which will translate this into a SIP call and
   deliver it to an administrative domain with a STIR verification
   service.

   In this case, the Internet gateway that receives the call from the
   PSTN can query the appropriate CPS to determine if the original
   caller created and provisioned a PASSporT for this call.  If so, it
   can retrieve the PASSporT and, when it creates a SIP INVITE for this
   call, add a corresponding Identity header per



Rescorla & Peterson        Expires May 4, 2017                  [Page 6]


Internet-Draft                STIR Fallback                 October 2016


   [I-D.ietf-stir-rfc4474bis].  When the SIP INVITE reaches the
   destination administrative domain, it will be able to verify the
   PASSporT normally.  Note that to avoid discrepancies with the Date
   header field value, only full-form PASSporT should be used for this
   purpose.

5.4.  Case 4: Gateway Out-of-band

   A call originates in the SIP world in a STIR-aware administrative
   domain.  The local authentication service for that administrative
   domain creates a PASSporT which is carried in band in the call per
   [I-D.ietf-stir-rfc4474bis].  The call is routed out of the
   originating administrative domain and eventually reaches a gateway to
   the PSTN.

   In this case, the originating authentication service does not support
   the out-of-band mechanism, so instead the gateway to the PSTN
   extracts the PASSporT from the SIP request and provisions it to the
   CPS.  (When the call reaches the gateway to the PSTN, the gateway
   might first check the CPS to see if a PASSporT object had already
   been provisioned for this call, and only provision a PASSporT if none
   is present).

   Ultimately, the call may terminate on the PSTN, or be routed back to
   the IP world.  In the former case, perhaps the destination endpoints
   queries the CPS to retrieve the PASSporT provisioned by the first
   gateway.  Or if the call ultimately returns to the IP world, it might
   be the gateway from the PSTN back to the Internet that retrieves the
   PASSporT from the CPS and attaches it to the new SIP INVITE it
   creates, or it might be the terminating administrative domain's
   verification service that checks the CPS when an INVITE arrives with
   no Identity header field.  Either way the PASSporT can survive the
   gap in SIP coverage caused by the PSTN leg of the call.

6.  Solution Architecture

   In this section, we discuss a strawman architecture along the lines
   described in the previous section.  This discussion is deliberately
   sketchy, focusing on broad concepts and skipping over details.  The
   intent here is merely to provide a rough concept, not a complete
   solution.

6.1.  Credentials and Phone Numbers

   We start from the premise of the STIR problem statement [RFC7340]
   that phone numbers can be associated with credentials which can be
   used to attest ownership of numbers.  For purposes of exposition, we
   will assume that ownership is associated with the endpoint (e.g., a



Rescorla & Peterson        Expires May 4, 2017                  [Page 7]


Internet-Draft                STIR Fallback                 October 2016


   smartphone) but it might well be associated with a provider or
   gateway acting for the endpoint instead.  It might be the case that
   multiple entities are able to act for a given number, provided that
   they have the appropriate authority.  [I-D.ietf-stir-certificates]
   describes a credentials system suitable for this purpose; the
   question of how an entity is determined to have control of a given
   number is out of scope for the current document.

6.2.  Solution Architecture

   An overview of the basic calling and verification process is shown
   below.  In this diagram, we assume that Alice has the number
   +1.111.111.1111 and Bob has the number +2.222.222.2222.

Alice                       Call Placement Service                  Bob
-----------------------------------------------------------------------
<-  Authenticate as 1.111.111.1111  ---->

Store PASSporT ->

Call from 1.111.111.1111 ---------------------------------------------->


                               <-  Authenticate as 1.222.222.2222  ---->

                                    <-------------- Retrieve call record
                                                    from 1.111.111.1111?

                                     (1.222.222.2222,1.111.111.1111) -->

                                               [Ring phone with callerid
                                                       = 1.111.111.1111]

   When Alice wishes to make a call to Bob, she contacts the CPS and
   authenticates to prove her ownership of her E.164 number.  Once she
   has authenticated, she then stores a PASSporT on the CPS.  The
   PASSpoRT is stored under Bob's number.

   Once Alice has stored the PASSporT, she then places the call to Bob
   as usual.  At this point, Bob's phone would usually ring and display
   Alice's number (+1.111.111.1111), which is informed by the existing
   caller-id mechanisms (i.e., the CIN field of the IAM).  Instead,
   Bob's phone transparently contacts the CPS and requests any current
   PASSporTs for calls to Bob.  The CPS responds with any such PASSporTs
   (assuming they exists).  If such a PASSpoRT exists, Bob's phone can
   then present the callerid information as valid.  Otherwise, the call
   is unverifiable.  Note that this does not necessarily mean that the




Rescorla & Peterson        Expires May 4, 2017                  [Page 8]


Internet-Draft                STIR Fallback                 October 2016


   call is bogus; because we expect incremental deployment many
   legitimate calls will be unverifiable.

6.3.  Security Analysis

   The primary attack we seek to prevent is an attacker convincing the
   callee that a given call is from some other caller C.  There are two
   scenarios to be concerned with:

      The attacker wishes to simulate a call when none exists.

      The attacker wishes to substitute himself for an existing call as
      described in Section 6.4.

   If an attacker can inject fake PASSporT into the CPS or in the
   communication from the CPS to the callee, he can mount either attack.
   As PASSporTs should be digitally signed by an appropriate authority
   for the number and verified by the callee (see Section 6.1), this
   should not arise in ordinary operations.  For privacy and robustness
   reasons, using TLS on the originating side when storing the PASSporT
   at the CPS is recommended.

   The entire system depends on the security of the credential
   infrastructure.  If the authentication credentials for a given number
   are compromised, then an attacker can impersonate calls from that
   number.

6.4.  Substitution Attacks

   All that receipt of the PASSporT from the CPS proves to the called
   party is that Alice is trying to call Bob (or at least was as of very
   recently).  It does not prove that any particular incoming call is
   from Alice.  Consider the scenario in which we have a service which
   provides an automatic callback to a user-provided number.  In that
   case, the attacker try to arrange for a false caller-id value, as
   shown below:















Rescorla & Peterson        Expires May 4, 2017                  [Page 9]


Internet-Draft                STIR Fallback                 October 2016


 Attacker            Callback Service              CPS               Bob
 -----------------------------------------------------------------------
 Place call to Bob ---------->

                             Store PASSporT for
                             CS:Bob -------------->

 Call from CS (forged caller-id info)  -------------------------------->

                             Call from CS ---------------------------> X


                                                <----- Retrieve PASSporT
                                                              for CS:Bob

                        PASSporT for CS:Bob --------------------------->

                                         [Ring phone with callerid = CS]

   In order to mount this attack, the attacker contacts the Callback
   Service (CS) and provides it with Bob's number.  This causes the CS
   to initiate a call to Bob. As before, the CS contacts the CPS to
   insert an appropriate PASSporT and then initiates a call to Bob.
   Because it is a valid CS injecting the PASSporT, none of the security
   checks mentioned above help.  However, the attacker simultaneously
   initiates a call to Bob using forged caller-id information
   corresponding to the CS.  If he wins the race with the CS, then Bob's
   phone will attempt to verify the attacker's call (and succeed since
   they are indistinguishable) and the CS's call will go to busy/voice
   mail/call waiting.  Note: in a SIP environment, the callee might
   notice that there were multiple INVITEs and thus detect this attack.

7.  Call Placement Service Discovery and Interface

   In order for the two ends of the out-of-band dataflow to coordinate,
   they must agree on a way to discover a CPS and retrieve PASSporT
   objects from it based solely on the rendezvous information available:
   the calling party number and the called number.  There are a number
   of potential service discovery mechanisms that could be used for this
   purpose.  The means of service discovery may vary by use case.

   There exist a number of common directory systems that might be used
   to translate telephone numbers into the URIs of a CPS.  ENUM
   [RFC6116] is commonly implemented, though no "golden root" central
   ENUM administration exists that could be easily reused today to help
   the endpoints discover a common CPS.  Other protocols associated with
   queries for telephone numbers, such as the TeRI




Rescorla & Peterson        Expires May 4, 2017                 [Page 10]


Internet-Draft                STIR Fallback                 October 2016


   [I-D.peterson-modern-teri] protocol, could also serve for this
   application.

   Another possibility is to use a single distributed service for this
   function.  VIPR [I-D.rosenberg-dispatch-vipr-overview] proposed a
   RELOAD [RFC6940] usage for telephone numbers to help direct calls to
   enterprises on the Internet.  It would be possible to describe a
   similar RELOAD usage to identify the CPS where calls for a particular
   telephone number should be stored.  One advantage that the STIR
   architecture has over VIPR is that it assumes a credential system
   that proves authority over telephone numbers; those credentials could
   be used to determine whether or not a CPS could legitimately claim to
   be the proper store for a given telephone number.

   Future versions of this specification will identify suitable service
   discovery mechanisms for out-of-band STIR.

8.  Some Potential Enhancements

   Section 4 provides a broad sketch of an approach.  In this section,
   we consider some potential enhancements.  Readers can feel free to
   skip this section, as it is not necessary to get the flavor of the
   document.

8.1.  Encrypted PASSporTs

   In the system described in Section 4, the CPS learns the PASSporT for
   every call, which is undesirable from a privacy perspective.  The
   situation can be improved by having the caller store encrypted
   PASSporTs.  A number of schemes are possible, but for concreteness we
   sketch one possibility.

   The general idea is that each user's credentials are not just
   suitable for authentication to the CPS but also are an asymmetric key
   pair suitable for use in an encryption mode.  When Alice wants to
   store a PASSporT for Bob she retrieves Bob's credentials (see
   Section 8.1.1) and then encrypts the PASSporT under Bob's public key.
   [The encryption needs to be done in such a way that if you don't have
   Bob's key, the message is indistinguishable from random.  This is
   straightforward, but not compatible with typical secure message
   formats, which tend to indicate the recipient's identity.]  The
   PASSporT is then stored with the CPS under Alice's identity.  When
   Bob receives a call, he just asks the CPS (anonymously) for any calls
   from Alice to anyone.  He then trial-decrypts each and if any of them
   is for him, he proceeds as before.  In this way, the CPS learns
   Alice's call velocity but not who she is calling.  This mechanism is
   suitable for cases where credentials are issued to end-user devices,
   rather than large operators.



Rescorla & Peterson        Expires May 4, 2017                 [Page 11]


Internet-Draft                STIR Fallback                 October 2016


8.1.1.  Credential Lookup

   In order to encrypt a PASSporT, the caller needs access to the
   callee's credentials (specifically their public key).  This requires
   some sort of directory/lookup system.  This document does not specify
   any particular scheme, but a list of requirements would be something
   like:

   Obviously, if there is a single central database and the caller and
   callee each contact it in real time to determine the other's
   credentials, then this represents a real privacy risk, as the central
   database learns about each call.  A number of mechanisms are
   potentially available to mitigate this:

      Have endpoints pre-fetch credentials for potential counterparties
      (e.g., their address book or the entire database).

      Have caching servers in the user's network that proxy their
      fetches and thus conceal the relationship between the user and the
      credentials they are fetching.

   Clearly, there is a privacy/timeliness tradeoff in that getting
   really up-to-date knowledge about credential validity requires
   contacting the credential directory in real-time (e.g., via OCSP).
   This is somewhat mitigated for the caller's credentials in that he
   can get short-term credentials right before placing a call which only
   reveals his calling rate, but not who he is calling.  Alternately,
   the CPS can verify the caller's credentials via OCSP, though of
   course this requires the callee to trust the CPS's verification.
   This approach does not work as well for the callee's credentials, but
   the risk there is more modest since an attacker would need to both
   have the callee's credentials and regularly poll the database for
   every potential caller.

   We consider the exact best point in the tradeoff space to be an open
   issue.

8.2.  Federated Call Placement Services

   The discussion above is written in terms of a single CPS, but this
   potentially has scaling problems, as well as allowing the CPS to
   learn about every call.  These issues can be alleviated by having a
   federated CPS.  If a credential lookup service is already available,
   the CPS location can also be stored in the callee's credentials.

   A service discovery mechanism for out-of-band STIR should ideally
   enable federation of the CPS function.




Rescorla & Peterson        Expires May 4, 2017                 [Page 12]


Internet-Draft                STIR Fallback                 October 2016


8.3.  Escalation to VoIP

   If the call is to be carried over the PSTN, then the security
   properties described above are about the best we can do.  However, if
   Alice and Bob are both VoIP capable, then there is an opportunity to
   provide a higher quality of service and security.  The basic idea is
   that the PASSporT contains an addition claim containing rendezvous
   information for Alice (e.g., Alice's SIP URI).  Once Bob has verified
   Alice's PASSporT, he can initiate a VoIP connection directly to
   Alice, thus bypassing the PSTN.  Mechanisms of this type are out of
   scope of this document.

9.  Acknowledgments

   The ideas in this document come out of discussions with Richard
   Barnes and Cullen Jennings.

10.  IANA Considerations

   This memo includes no request to IANA.

11.  Security Considerations

   This entire document is about security, but the detailed security
   properties depend on having a single concrete scheme to analyze.

12.  Informative References

   [I-D.ietf-stir-certificates]
              Peterson, J. and S. Turner, "Secure Telephone Identity
              Credentials: Certificates", draft-ietf-stir-
              certificates-10 (work in progress), October 2016.

   [I-D.ietf-stir-passport]
              Wendt, C. and J. Peterson, "Personal Assertion Token
              (PASSporT)", draft-ietf-stir-passport-10 (work in
              progress), October 2016.

   [I-D.ietf-stir-rfc4474bis]
              Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
              "Authenticated Identity Management in the Session
              Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-14
              (work in progress), October 2016.

   [I-D.peterson-modern-teri]
              Peterson, J., "An Architecture and Information Model for
              Telephone-Related Information (TeRI)", draft-peterson-
              modern-teri-01 (work in progress), July 2016.



Rescorla & Peterson        Expires May 4, 2017                 [Page 13]


Internet-Draft                STIR Fallback                 October 2016


   [I-D.rosenberg-dispatch-vipr-overview]
              Rosenberg, J., Jennings, C., and M. Petit-Huguenin,
              "Verification Involving PSTN Reachability: Requirements
              and Architecture Overview", draft-rosenberg-dispatch-vipr-
              overview-04 (work in progress), October 2010.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              DOI 10.17487/RFC3261, June 2002,
              <http://www.rfc-editor.org/info/rfc3261>.

   [RFC6116]  Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to
              Uniform Resource Identifiers (URI) Dynamic Delegation
              Discovery System (DDDS) Application (ENUM)", RFC 6116,
              DOI 10.17487/RFC6116, March 2011,
              <http://www.rfc-editor.org/info/rfc6116>.

   [RFC6940]  Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S.,
              and H. Schulzrinne, "REsource LOcation And Discovery
              (RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940,
              January 2014, <http://www.rfc-editor.org/info/rfc6940>.

   [RFC7340]  Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
              Telephone Identity Problem Statement and Requirements",
              RFC 7340, DOI 10.17487/RFC7340, September 2014,
              <http://www.rfc-editor.org/info/rfc7340>.

Authors' Addresses

   Eric Rescorla
   Mozilla

   Email: ekr@rtfm.com


   Jon Peterson
   Neustar, Inc.
   1800 Sutter St Suite 570
   Concord, CA  94520
   US

   Email: jon.peterson@neustar.biz



Rescorla & Peterson        Expires May 4, 2017                 [Page 14]

Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/