path: root/doc/rfc/rfc8816.txt

Internet Engineering Task Force (IETF)                       E. Rescorla
Request for Comments: 8816                                       Mozilla
Category: Informational                                      J. Peterson
ISSN: 2070-1721                                                  Neustar
                                                           February 2021


Secure Telephone Identity Revisited (STIR) Out-of-Band Architecture and
                               Use Cases

Abstract

   The Personal Assertion Token (PASSporT) format defines a token that
   can be carried by signaling protocols, including SIP, to
   cryptographically attest the identity of callers.  However, not all
   telephone calls use Internet signaling protocols, and some calls use
   them for only part of their signaling path, while some cannot
   reliably deliver SIP header fields end-to-end.  This document
   describes use cases that require the delivery of PASSporT objects
   outside of the signaling path, and defines architectures and
   semantics to provide this functionality.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are candidates for any level of Internet
   Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8816.

Copyright Notice

   Copyright (c) 2021 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
   (https://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.

Table of Contents

   1.  Introduction
   2.  Terminology
   3.  Operating Environments
   4.  Dataflows
   5.  Use Cases
     5.1.  Case 1: VoIP to PSTN Call
     5.2.  Case 2: Two Smart PSTN Endpoints
     5.3.  Case 3: PSTN to VoIP Call
     5.4.  Case 4: Gateway Out-of-Band
     5.5.  Case 5: Enterprise Call Center
   6.  Storing and Retrieving PASSporTs
     6.1.  Storage
     6.2.  Retrieval
   7.  Solution Architecture
     7.1.  Credentials and Phone Numbers
     7.2.  Call Flow
     7.3.  Security Analysis
     7.4.  Substitution Attacks
     7.5.  Rate Control for CPS Storage
   8.  Authentication and Verification Service Behavior for
           Out-of-Band
     8.1.  Authentication Service (AS)
     8.2.  Verification Service (VS)
     8.3.  Gateway Placement Services
   9.  Example HTTPS Interface to the CPS
   10. CPS Discovery
   11. Encryption Key Lookup
   12. IANA Considerations
   13. Privacy Considerations
   14. Security Considerations
   15. Informative References
   Acknowledgments
   Authors' Addresses

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, [RFC8224] defines a SIP Identity header
   field capable of carrying PASSporT objects [RFC8225] 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.

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

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

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

   3.  Non-PSTN calls that 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 in-band signaling data -- intact.  Even if fields for
   tunneling arbitrary data can be found in traditional PSTN signaling,
   in some cases legacy elements would strip the signatures from those
   fields; 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.

   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 Private Branch Exchanges (PBXs), and terminal adapters.  All three
   are general purpose computers, and typically all three have Internet
   access as well as access to the PSTN; they may be used for
   residential, mobile, or enterprise telephone services.  Additionally,
   various kinds of gateways increasingly front for deployments of
   legacy PBX and PSTN switches.  All of this provides a potential
   avenue for building an authentication system that implements stronger
   identity while leaving PSTN systems intact.

   This capability also provides an ideal transitional technology while
   in-band STIR adoption is ramping up.  It permits early adopters to
   use the technology even when intervening network elements are not yet
   STIR-aware, and through various kinds of gateways, it may allow
   providers with a significant PSTN investment to still secure their
   calls with STIR.

   The techniques described in this document therefore build on the
   PASSporT [RFC8225] mechanism and the work of [RFC8224] to describe a
   way that a PASSporT object created in the originating network of a
   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 called a Call Placement Service
   (CPS) that permits the PASSporT object to be stored during call
   processing and retrieved for verification purposes.

   Potential implementors should note that this document merely defines
   the operating environments in which this out-of-band STIR mechanism
   is intended to operate.  It provides use cases, gives a broad
   description of the components, and a potential solution architecture.
   Various environments may have their own security requirements: a
   public deployment of out-of-band STIR faces far greater challenges
   than a constrained intra-network deployment.  To flesh out the
   storage and retrieval of PASSporTs in the CPS within this context,
   this document includes a strawman protocol suitable for that purpose.
   Deploying this framework in any given environment would require
   additional specification outside the scope of this document.

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 BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Operating Environments

   This section describes the environments in which the proposed out-of-
   band STIR mechanism is intended to operate.  In the simplest setting,
   Alice calls Bob, and her call is routed through some set of gateways
   and/or the PSTN that do not support end-to-end delivery of STIR.
   Both Alice and Bob have smart devices that can access the Internet
   (perhaps enterprise devices, or even end-user ones), but they do not
   have a clear telephone signaling connection between them: Alice
   cannot inject any data into signaling that 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 instead just a traditional telephone.
   However, 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 (e.g., PSTN) connection to
   her gateway or switch that 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 Plain Old Telephone Service (POTS) mechanisms.

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 11 for limitations
   of this design.)

   This architecture does not mandate that any particular sort of entity
   operate a CPS or mandate any means to discover a CPS.  A CPS could be
   run internally within a network or made publicly available.  One or
   more CPSes could be run by a carrier, as repositories for PASSporTs
   for calls sent to its customers, or a CPS could be built into an
   enterprise PBX or even a smartphone.  To the degree possible, it is
   specified here generically as an idea that may have applicability to
   a variety of STIR deployments.

   There are roughly two plausible dataflow architectures for the CPS:

   1.  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 immediately forwards it to the callee.

   2.  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 PASSporT.

   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.  Indeed, if the
   endpoints had the capabilities to implement such an architecture,
   they could surely just use SIP or some other protocol to set up a
   secure session; even if the media were going through the traditional
   PSTN, a "shadow" SIP session could convey the PASSporT.  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.  In specialized environments, for
   example, a call center that receives a large volume of incoming calls
   that originated in the PSTN, the notification channel approach might
   be viable.

5.  Use Cases

   The following are the motivating use cases for this mechanism.  Bear
   in mind that, just as in [RFC8224], there may be multiple Identity
   header fields 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.

5.1.  Case 1: VoIP to PSTN Call

   A call originates in a SIP environment in a STIR-aware administrative
   domain.  The local authentication service for that administrative
   domain creates a PASSporT that is carried in band in the call per
   [RFC8224].  The call is routed out of the originating administrative
   domain and 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 (per the practices of
   Section 10) 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, which communicates through
   traditional telephone signaling protocols.  The PBX immediately
   routes the 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 immediately route
   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, there are two subcases for how the PASSporT might be
   retrieved.  In subcase 1, the Internet gateway that receives the call
   from the PSTN could 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 field per
   [RFC8224].  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 a full-form PASSporT should be used for this
   purpose.  In subcase 2, the gateway does not retrieve the PASSporT
   itself, but instead the verification service at the destination
   administrative domain does so.  Subcase 1 would perhaps be valuable
   for deployments where the destination administrative domain supports
   in-band STIR but not out-of-band STIR.

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 that is carried in band in the call per
   [RFC8224].  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 a
   SIP environment.  In the former case, perhaps the destination
   endpoint queries the CPS to retrieve the PASSporT provisioned by the
   first gateway.  If the call ultimately returns to a SIP environment,
   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.

5.5.  Case 5: Enterprise Call Center

   A call originates from a mobile user, and a STIR authentication
   service operated by their carrier creates a PASSporT for the call.
   As the carrier forwards the call via SIP, it attaches the PASSporT to
   the SIP call with an Identity header field.  As a fallback in case
   the call will not go end-to-end over SIP, the carrier also stores the
   PASSporT in a CPS.

   The call is then routed over SIP for a time, before it transitions to
   the PSTN and ultimately is handled by a legacy PBX at a high-volume
   call center.  The call center supports the out-of-band service, and
   has a high-volume interface to a CPS to retrieve PASSporTs for
   incoming calls; agents at the call center use a general purpose
   computer to manage inbound calls and can receive STIR notifications
   through it.  When the PASSporT arrives at the CPS, it is sent through
   a subscription/notification interface to a system that can correlate
   incoming calls with valid PASSporTs.  The call center agent sees that
   a valid call from the originating number has arrived.

6.  Storing and Retrieving PASSporTs

   The use cases show a variety of entities accessing the CPS to store
   and retrieve PASSporTs.  The question of how the CPS authorizes the
   storage and retrieval of PASSporTs is thus a key design decision in
   the architecture.  The STIR architecture assumes that service
   providers and, in some cases, end-user devices will have credentials
   suitable for attesting authority over telephone numbers per
   [RFC8226].  These credentials provide the most obvious way that a CPS
   can authorize the storage and retrieval of PASSporTs.  However, as
   use cases 3, 4, and 5 in Section 5 show, it may sometimes make sense
   for the entity storing or retrieving PASSporTs to be an intermediary
   rather than a device associated with either the originating or
   terminating side of a call; those intermediaries often would not have
   access to STIR credentials covering the telephone numbers in
   question.  Requiring authorization based on a credential to store
   PASSporTs is therefore undesirable, though potentially acceptable if
   sufficient steps are taken to mitigate any privacy risk of leaking
   data.

   It is an explicit design goal of this mechanism to minimize the
   potential privacy exposure of using a CPS.  Ideally, the out-of-band
   mechanism should not result in a worse privacy situation than in-band
   STIR [RFC8224]: for in-band, we might say that a SIP entity is
   authorized to receive a PASSporT if it is an intermediate or final
   target of the routing of a SIP request.  As the originator of a call
   cannot necessarily predict the routing path a call will follow, an
   out-of-band mechanism could conceivably even improve on the privacy
   story.

   Broadly, the architecture recommended here thus is one focused on
   permitting any entity to store encrypted PASSporTs at the CPS,
   indexed under the called number.  PASSporTs will be encrypted with a
   public key associated with the called number, so these PASSporTs may
   safely be retrieved by any entity because only holders of the
   corresponding private key will be able to decrypt the PASSporT.  This
   also prevents the CPS itself from learning the contents of PASSporTs,
   and thus metadata about calls in progress, which makes the CPS a less
   attractive target for pervasive monitoring (see [RFC7258]).  As a
   first step, transport-level security can provide confidentiality from
   eavesdroppers for both the storing and retrieval of PASSporTs.  To
   bolster the privacy story, to prevent denial-of-service flooding of
   the CPS, and to complicate traffic analysis, a few additional
   mechanisms are also recommended below.

6.1.  Storage

   There are a few dimensions to authorizing the storage of PASSporTs.
   Encrypting PASSporTs prior to storage entails that a CPS has no way
   to tell if a PASSporT is valid; it simply conveys encrypted blocks
   that it cannot access itself and can make no authorization decision
   based on the PASSporT contents.  There is certainly no prospect for
   the CPS to verify the PASSporTs itself.

   Note that this architecture requires clients that store PASSporTs to
   have access to an encryption key associated with the intended called
   party to be used to encrypt the PASSporT.  Discovering this key
   requires the existence of a key lookup service (see Section 11),
   depending on how the CPS is architected; however, some kind of key
   store or repository could be implemented adjacent to it and perhaps
   even incorporated into its operation.  Key discovery is made more
   complicated by the fact that there can potentially be multiple
   entities that have authority over a telephone number: a carrier, a
   reseller, an enterprise, and an end user might all have credentials
   permitting them to attest that they are allowed to originate calls
   from a number, say.  PASSporTs for out-of-band use therefore might
   need to be encrypted with multiple keys in the hopes that one will be
   decipherable by the relying party.

   Again, the most obvious way to authorize storage is to require the
   originator to authenticate themselves to the CPS with their STIR
   credential.  However, since the call is indexed at the CPS under the
   called number, this can weaken the privacy story of the architecture,
   as it reveals to the CPS both the identity of the caller and the
   callee.  Moreover, it does not work for the gateway use cases
   described above; to support those use cases, we must effectively
   allow any entity to store PASSporTs at a CPS.  This does not degrade
   the anti-impersonation security of STIR, because entities who do not
   possess the necessary credentials to sign the PASSporT will not be
   able to create PASSporTs that will be treated as valid by verifiers.
   In this architecture, it does not matter whether the CPS received a
   PASSporT from the authentication service that created it or from an
   intermediary gateway downstream in the routing path as in case 4
   above.  However, if literally anyone can store PASSporTs in the CPS,
   an attacker could easily flood the CPS with millions of bogus
   PASSporTs indexed under a calling number, and thereby prevent the
   called party from finding a valid PASSporT for an incoming call
   buried in a haystack of fake entries.

   The solution architecture must therefore include some sort of traffic
   control system to prevent flooding.  Preferably, this should not
   require authenticating the source, as this will reveal to the CPS
   both the source and destination of traffic.  A potential solution is
   discussed below in Section 7.5.

6.2.  Retrieval

   For retrieval of PASSporTs, this architecture assumes that clients
   will contact the CPS through some sort of polling or notification
   interface to receive all current PASSporTs for calls destined to a
   particular telephone number, or block of numbers.

   As PASSporTs stored at the CPS are encrypted with a key belonging to
   the intended destination, the CPS can safely allow anyone to download
   PASSporTs for a called number without much fear of compromising
   private information about calls in progress -- provided that the CPS
   always returns at least one encrypted blob in response to a request,
   even if there was no call in progress.  Otherwise, entities could
   poll the CPS constantly, or eavesdrop on traffic, to learn whether or
   not calls were in progress.  The CPS MUST generate at least one
   unique and plausible encrypted response to all retrieval requests,
   and these dummy encrypted PASSporTs MUST NOT be repeated for later
   calls.  An encryption scheme needs to be carefully chosen to make
   messages look indistinguishable from random when encrypted, so that
   information about the called party is not discoverable from
   legitimate encrypted PASSporTs.

   Because the entity placing a call may discover multiple keys
   associated with the called party number, multiple valid PASSporTs may
   be stored in the CPS.  A particular called party who retrieves
   PASSporTs from the CPS may have access to only one of those keys.
   Thus, the presence of one or more PASSporTs that the called party
   cannot decrypt -- which would be indistinguishable from the "dummy"
   PASSporTs created by the CPS when no calls are in progress - does not
   entail that there is no call in progress.  A retriever likely will
   need to decrypt all PASSporTs retrieved from the CPS, and may find
   only one that is valid.

   In order to prevent the CPS from learning the numbers that a callee
   controls, callees might also request PASSporTs for numbers that they
   do not own, that they have no hope of decrypting.  Implementations
   could even allow a callee to request PASSporTs for a range or prefix
   of numbers: a trade-off where that callee is willing to sift through
   bulk quantities of undecryptable PASSporTs for the sake of hiding
   from the CPS which numbers it controls.

   Note that in out-of-band call forwarding cases, special behavior is
   required to manage the relationship between PASSporTs using the
   diversion extension [PASSPORT-DIVERT].  The originating
   authentication service encrypts the initial PASSporT with the public
   encryption key of the intended destination, but once a call is
   forwarded, it may go to a destination that does not possess the
   corresponding private key and thus could not decrypt the original
   PASSporT.  This requires the retargeting entity to generate encrypted
   PASSporTs that show a secure chain of diversion: a retargeting storer
   SHOULD use the "div-o" PASSporT type, with its "opt" extension, as
   specified in [PASSPORT-DIVERT], in order to nest the original
   PASSporT within the encrypted diversion PASSporT.

7.  Solution Architecture

   In this section, we discuss a high-level architecture for providing
   the service described in the previous sections.  This discussion is
   deliberately sketchy, focusing on broad concepts and skipping over
   details.  The intent here is merely to provide an overall
   architecture, not an implementable specification.  A more concrete
   example of how this might be specified is given in Section 9.

7.1.  Credentials and Phone Numbers

   We start from the premise of the STIR problem statement [RFC7340]
   that phone numbers can be associated with credentials that 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
   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.  [RFC8226] describes a
   credential 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 this document.

7.2.  Call Flow

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

   Alice                    Call Placement Service                  Bob
   --------------------------------------------------------------------

   Store Encrypted PASSporT for 2.222.555.2222 ->

   Call from 1.111.555.1111 ------------------------------------------>


                                    <-------------- Request PASSporT(s)
                                     for 2.222.555.2222

                                    Obtain Encrypted PASSporT -------->
                                       (2.222.555.2222, 1.111.555.1111)

                                     [Ring phone with verified callerid
                                                      = 1.111.555.1111]

   When Alice wishes to make a call to Bob, she contacts the CPS and
   stores an encrypted PASSporT on the CPS indexed under Bob's number.
   The CPS then awaits retrievals for that number.

   When Alice places the call, Bob's phone would usually ring and
   display Alice's number (+1.111.555.1111), which is informed by the
   existing PSTN mechanisms for relaying a calling party number (e.g.,
   the Calling Party's Number (CIN) field of the Initial Address Message
   (IAM)).  Instead, Bob's phone transparently contacts the CPS and
   requests any current PASSporTs for calls to his number.  The CPS
   responds with any such PASSporTs (or dummy PASSporTs if no relevant
   ones are currently stored).  If such a PASSporT exists, and the
   verification service in Bob's phone decrypts it using his private
   key, validates it, then Bob's phone can present the calling party
   number information as valid.  Otherwise, the call is unverifiable.
   Note that this does not necessarily mean that the call is bogus;
   because we expect incremental deployment, many legitimate calls will
   be unverifiable.

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

   1.  The attacker wishes to impersonate a target when no call from
       that target is in progress.

   2.  The attacker wishes to substitute himself for an existing call
       setup.

   If an attacker can inject fake PASSporTs 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 7.1), this
   should not arise in ordinary operations.  Any attacker who is aware
   of calls in progress can attempt to mount a race to substitute
   themselves as described in Section 7.4.  For privacy and robustness
   reasons, using TLS [RFC8446] 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.  However, that is no different from in-band STIR [RFC8224].

   A secondary attack we must also prevent is denial-of-service against
   the CPS, which requires some form of rate control solution that will
   not degrade the privacy properties of the architecture.

7.4.  Substitution Attacks

   All that the 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
   that provides an automatic callback to a user-provided number.  In
   that case, the attacker can try to arrange for a false caller-id
   value, as shown below:

    Attacker            Callback Service           CPS               Bob
    --------------------------------------------------------------------
    Place call to Bob ---------->
     (from 111.555.1111)
                                Store PASSporT for
                                CS:Bob ------------->

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

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


                                                   <-- Retrieve PASSporT
                                                              for CS:Bob

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

                                            [Ring phone with callerid =
                                               111.555.1111]

   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.

   In order to prevent a passive attacker from using traffic analysis or
   similar means to learn precisely when a call is placed, it is
   essential that the connection between the caller and the CPS be
   encrypted as recommended above.  Authentication services could store
   dummy PASSporTs at the CPS at random intervals in order to make it
   more difficult for an eavesdropper to use traffic analysis to
   determine that a call was about to be placed.

   Note that in a SIP environment, the callee might notice that there
   were multiple INVITEs and thus detect this attack, but in some PSTN
   interworking scenarios, or highly intermediated networks, only one
   call setup attempt will reach the target.  Also note that the success
   of this substitution attack depends on the attacker landing their
   call within the narrow window that the PASSporT is retained in the
   CPS, so shortening that window will reduce the opportunity for the
   attack.  Finally, smart endpoints could implement some sort of state
   coordination to ensure that both sides believe the call is in
   progress, though methods of supporting that are outside the scope of
   this document.

7.5.  Rate Control for CPS Storage

   In order to prevent the flooding of a CPS with bogus PASSporTs, we
   propose the use of "blind signatures" (see [RFC5636]).  A sender will
   initially authenticate to the CPS using its STIR credentials and
   acquire a signed token from the CPS that will be presented later when
   storing a PASSporT.  The flow looks as follows:

       Sender                                 CPS

       Authenticate to CPS --------------------->
       Blinded(K_temp) ------------------------->
       <------------- Sign(K_cps, Blinded(K_temp))
       [Disconnect]


       Sign(K_cps, K_temp)
       Sign(K_temp, E(K_receiver, PASSporT)) --->

   At an initial time when no call is yet in progress, a potential
   client connects to the CPS, authenticates, and sends a blinded
   version of a freshly generated public key.  The CPS returns a signed
   version of that blinded key.  The sender can then unblind the key and
   get a signature on K_temp from the CPS.

   Then later, when a client wants to store a PASSporT, it connects to
   the CPS anonymously (preferably over a network connection that cannot
   be correlated with the token acquisition) and sends both the signed
   K_temp and its own signature over the encrypted PASSporT.  The CPS
   verifies both signatures and, if they verify, stores the encrypted
   passport (discarding the signatures).

   This design lets the CPS rate limit how many PASSporTs a given sender
   can store just by counting how many times K_temp appears; perhaps CPS
   policy might reject storage attempts and require acquisition of a new
   K_temp after storing more than a certain number of PASSporTs indexed
   under the same destination number in a short interval.  This does
   not, of course, allow the CPS to tell when bogus data is being
   provisioned by an attacker, simply the rate at which data is being
   provisioned.  Potentially, feedback mechanisms could be developed
   that would allow the called parties to tell the CPS when they are
   receiving unusual or bogus PASSporTs.

   This architecture also assumes that the CPS will age out PASSporTs.
   A CPS SHOULD NOT keep any stored PASSporT for longer than the
   recommended freshness policy for the "iat" value as described in
   [RFC8224] (i.e., sixty seconds) unless some local policy for a CPS
   deployment requires a longer or shorter interval.  Any reduction in
   this window makes substitution attacks (see Section 7.4) harder to
   mount, but making the window too small might conceivably age
   PASSporTs out while a heavily redirected call is still alerting.

   An alternative potential approach to blind signatures would be the
   use of verifiable oblivious pseudorandom functions (VOPRFs, per
   [PRIVACY-PASS]), which may prove faster.

8.  Authentication and Verification Service Behavior for Out-of-Band

   [RFC8224] defines an authentication service and a verification
   service as functions that act in the context of SIP requests and
   responses.  This specification thus provides a more generic
   description of authentication service and verification service
   behavior that might or might not involve any SIP transactions, but
   depends only on placing a request for communications from an
   originating identity to one or more destination identities.

8.1.  Authentication Service (AS)

   Out-of-band authentication services perform steps similar to those
   defined in [RFC8224] with some exceptions:

   Step 1: The authentication service MUST determine whether it is
   authoritative for the identity of the originator of the request, that
   is, the identity it will populate in the "orig" claim of the
   PASSporT.  It can do so only if it possesses the private key of one
   or more credentials that can be used to sign for that identity, be it
   a domain or a telephone number or some other identifier.  For
   example, the authentication service could hold the private key
   associated with a STIR certificate [RFC8225].

   Step 2: The authentication service MUST determine that the originator
   of communications can claim the originating identity.  This is a
   policy decision made by the authentication service that depends on
   its relationship to the originator.  For an out-of-band application
   built into the calling device, for example, this is the same check
   performed in Step 1: does the calling device hold a private key, one
   corresponding to a STIR certificate, that can sign for the
   originating identity?

   Step 3: The authentication service MUST acquire the public encryption
   key of the destination, which will be used to encrypt the PASSporT
   (see Section 11).  It MUST also discover (see Section 10) the CPS
   associated with the destination.  The authentication service may
   already have the encryption key and destination CPS cached, or may
   need to query a service to acquire the key.  Note that per
   Section 7.5, the authentication service may also need to acquire a
   token for PASSporT storage from the CPS upon CPS discovery.  It is
   anticipated that the discovery mechanism (see Section 10) used to
   find the appropriate CPS will also find the proper key server for the
   public key of the destination.  In some cases, a destination may have
   multiple public encryption keys associated with it.  In that case,
   the authentication service MUST collect all of those keys.

   Step 4: The authentication service MUST create the PASSporT object.
   This includes acquiring the system time to populate the "iat" claim,
   and populating the "orig" and "dest" claims as described in
   [RFC8225].  The authentication service MUST then encrypt the
   PASSporT.  If in Step 3 the authentication service discovered
   multiple public keys for the destination, it MUST create one
   encrypted copy for each public key it discovered.

   Finally, the authentication service stores the encrypted PASSporT(s)
   at the CPS discovered in Step 3.  Only after that is completed should
   any call be initiated.  Note that a call might be initiated over SIP,
   and the authentication service would place the same PASSporT in the
   Identity header field value of the SIP request -- though SIP would
   carry a cleartext version rather than an encrypted version sent to
   the CPS.  In that case, out-of-band would serve as a fallback
   mechanism if the request was not conveyed over SIP end-to-end.  Also,
   note that the authentication service MAY use a compact form of the
   PASSporT for a SIP request, whereas the version stored at the CPS
   MUST always be a full-form PASSporT.

8.2.  Verification Service (VS)

   When a call arrives, an out-of-band verification service performs
   steps similar to those defined in [RFC8224] with some exceptions:

   Step 1: The verification service contacts the CPS and requests all
   current PASSporTs for its destination number; or alternatively it may
   receive PASSporTs through a push interface from the CPS in some
   deployments.  The verification service MUST then decrypt all
   PASSporTs using its private key.  Some PASSporTs may not be
   decryptable for any number of reasons: they may be intended for a
   different verification service, or they may be "dummy" values
   inserted by the CPS for privacy purposes.  The next few steps will
   narrow down the set of PASSporTs that the verification service will
   examine from that initial decryptable set.

   Step 2: The verification service MUST determine if any "ppt"
   extensions in the PASSporTs are unsupported.  It takes only the set
   of supported PASSporTs and applies the next step to them.

   Step 3: The verification service MUST determine if there is an
   overlap between the calling party number presented in call signaling
   and the "orig" field of any decrypted PASSporTs.  It takes the set of
   matching PASSporTs and applies the next step to them.

   Step 4: The verification service MUST determine if the credentials
   that signed each PASSporT are valid, and if the verification service
   trusts the CA that issued the credentials.  It takes the set of
   trusted PASSporTs to the next step.

   Step 5: The verification service MUST check the freshness of the
   "iat" claim of each PASSporT.  The exact interval of time that
   determines freshness is left to local policy.  It takes the set of
   fresh PASSporTs to the next step.

   Step 6: The verification service MUST check the validity of the
   signature over each PASSporT, as described in [RFC8225].

   Finally, the verification service will end up with one or more valid
   PASSporTs corresponding to the call it has received.  In keeping with
   baseline STIR, this document does not dictate any particular
   treatment of calls that have valid PASSporTs associated with them;
   the handling of the call after the verification process depends on
   how the verification service is implemented and on local policy.
   However, it is anticipated that local policies could involve making
   different forwarding decisions in intermediary implementations, or
   changing how the user is alerted or how identity is rendered in user
   agent implementations.

8.3.  Gateway Placement Services

   The STIR out-of-band mechanism also supports the presence of gateway
   placement services, which do not create PASSporTs themselves, but
   instead take PASSporTs out of signaling protocols and store them at a
   CPS before gatewaying to a protocol that cannot carry PASSporTs
   itself.  For example, a SIP gateway that sends calls to the PSTN
   could receive a call with an Identity header field, extract a
   PASSporT from the Identity header field, and store that PASSporT at a
   CPS.

   To place a PASSporT at a CPS, a gateway MUST perform Step 3 of
   Section 8.1 above: that is, it must discover the CPS and public key
   associated with the destination of the call, and may need to acquire
   a PASSporT storage token (see Section 6.1).  Per Step 3 of
   Section 8.1, this may entail discovering several keys.  The gateway
   then collects the in-band PASSporT(s) from the in-band signaling,
   encrypts the PASSporT(s), and stores them at the CPS.

   A similar service could be performed by a gateway that retrieves
   PASSporTs from a CPS and inserts them into signaling protocols that
   support carrying PASSporTs in-band.  This behavior may be defined by
   future specifications.

9.  Example HTTPS Interface to the CPS

   As a rough example, we show a CPS implementation here that uses a
   Representational State Transfer (REST) API [REST] to store and
   retrieve objects at the CPS.  The calling party stores the PASSporT
   at the CPS prior to initiating the call; the PASSporT is stored at a
   location at the CPS that corresponds to the called number.  Note that
   it is possible for multiple parties to be calling a number at the
   same time, and that for called numbers such as large call centers,
   many PASSporTs could legitimately be stored simultaneously, and it
   might prove difficult to correlate these with incoming calls.

   Assume that an authentication service has created the following
   PASSporT for a call to the telephone number 2.222.555.2222 (note that
   these are dummy values):

      eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9
      jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJkZXN0Ijp7InRuIjpbI
      jIyMjI1NTUyMjIyIl19LCJpYXQiOiIxNTgzMjUxODEwIiwib3JpZyI6eyJ0biI6
      IjExMTE1NTUxMTExIn19.pnij4IlLHoR4vxID0u3CT1e9Hq4xLngZUTv45Vbxmd
      3IVyZug4KOSa378yfP4x6twY0KTdiDypsereS438ZHaQ

   Through some discovery mechanism (see Section 10), the authentication
   service discovers the network location of a web service that acts as
   the CPS for 2.222.555.2222.  Through the same mechanism, we will say
   that it has also discovered one public encryption key for that
   destination.  It uses that encryption key to encrypt the PASSporT,
   resulting in the encrypted PASSporT:

      rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w
      MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm
      nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV
      wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1
      IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j

   Having concluded the numbered steps in Section 8.1, including
   acquiring any token (per Section 6.1) needed to store the PASSporT at
   the CPS, the authentication service then stores the encrypted
   PASSporT:

      POST /cps/2.222.555.2222/ppts HTTP/1.1
      Host: cps.example.com
      Content-Type: application/passport

      rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w
      MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm
      nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV
      wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1
      IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j

   The web service assigns a new location for this encrypted PASSporT in
   the collection, returning a 201 OK with the location of
   /cps/2.222.222.2222/ppts/ppt1.  Now the authentication service can
   place the call, which may be signaled by various protocols.  Once the
   call arrives at the terminating side, a verification service contacts
   its CPS to ask for the set of incoming calls for its telephone number
   (2.222.222.2222).

      GET /cps/2.222.555.2222/ppts
      Host: cps.example.com

   This returns to the verification service a list of the PASSporTs
   currently in the collection, which currently consists of only
   /cps/2.222.222.2222/ppts/ppt1.  The verification service then sends a
   new GET for /cps/2.222.555.2222/ppts/ppt1/ which yields:

      HTTP/1.1 200 OK
      Content-Type: application/passport
      Link: <https://cps.example.com/cps/2.222.555.2222/ppts>

      rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w
      MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm
      nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV
      wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1
      IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j

   That concludes Step 1 of Section 8.2; the verification service then
   goes on to the next step, processing that PASSporT through its
   various checks.  A complete protocol description for CPS interactions
   is left to future work.

10.  CPS Discovery

   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.  Because the storage
   of PASSporTs in this architecture is indexed by the called party
   number, it makes sense to discover a CPS based on the called party
   number as well.  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.

   Although the discussion above is written largely in terms of a single
   CPS, having a significant fraction of all telephone calls result in
   storing and retrieving PASSporTs at a single monolithic CPS has
   obvious scaling problems, and would as well allow the CPS to gather
   metadata about a very wide set of callers and callees.  These issues
   can be alleviated by operational models with a federated CPS; any
   service discovery mechanism for out-of-band STIR should enable
   federation of the CPS function.  Likely models include ones where a
   carrier operates one or more CPS instances on behalf of its
   customers, an enterprise runs a CPS instance on behalf of its PBX
   users, or a third-party service provider offers a CPS as a cloud
   service.

   Some service discovery possibilities under consideration include the
   following:

      For some deployments in closed (e.g., intra-network) environments,
      the CPS location can simply be provisioned in implementations,
      obviating the need for a discovery protocol.

      If a credential lookup service is already available (see
      Section 11), the CPS location can also be recorded in the callee's
      credentials; an extension to [RFC8226] could, for example, provide
      a link to the location of the CPS where PASSporTs should be stored
      for a destination.

      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
      Telephone-Related Information (TeRI) protocol [MODERN-TERI], could
      also serve for this application.

      Another possibility is to use a single distributed service for
      this function.  Verification Involving PSTN Reachability (VIPR)
      [VIPR-OVERVIEW] proposed a REsource LOcation And Discovery
      (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.

   This document does not prescribe any single way to do service
   discovery for a CPS; it is envisioned that initial deployments will
   provision the location of the CPS at the authentication service and
   verification service.

11.  Encryption Key Lookup

   In order to encrypt a PASSporT (see Section 6.1), the caller needs
   access to the callee's public encryption key.  Note that because STIR
   uses the Elliptic Curve Digital Signature Algorithm (ECDSA) for
   signing PASSporTs, the public key used to verify PASSporTs is not
   suitable for this function, and thus the encryption key must be
   discovered separately.  This requires some sort of directory/lookup
   system.

   Some initial STIR deployments have fielded certificate repositories
   so that verification services can acquire the signing credentials for
   PASSporTs, which are linked through a URI in the "x5u" element of the
   PASSporT.  These certificate repositories could clearly be repurposed
   for allowing authentication services to download the public
   encryption key for the called party -- provided they can be
   discovered by calling parties.  This document does not specify any
   particular discovery scheme, but instead offers some general guidance
   about potential approaches.

   It is a desirable property that the public encryption key for a given
   party be linked to their STIR credential.  An Elliptic Curve
   Diffie-Hellman (ECDH) [RFC7748] public-private key pair might be
   generated for a subcert [TLS-SUBCERTS] of the STIR credential.  That
   subcert could be looked up along with the STIR credential of the
   called party.  Further details of this subcert, and the exact lookup
   mechanism involved, are deferred for future protocol work.

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

      Have endpoints pre-fetch keys 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
      keys they are fetching.

   Clearly, there is a privacy/timeliness trade-off in that getting up-
   to-date knowledge about credential validity requires contacting the
   credential directory in real-time (e.g., via the Online Certificate
   Status Protocol (OCSP) [RFC6960]).  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 trade-off space to be an open
   issue.

12.  IANA Considerations

   This document has no IANA actions.

13.  Privacy Considerations

   Delivering PASSporTs out-of-band offers a different set of privacy
   properties than traditional in-band STIR.  In-band operations convey
   PASSporTs as headers in SIP messages in cleartext, which any
   forwarding intermediaries can potentially inspect.  By contrast, out-
   of-band STIR stores these PASSporTs at a service after encrypting
   them as described in Section 6, effectively creating a path between
   the authentication and verification service in which the CPS is the
   sole intermediary, but the CPS cannot read the PASSporTs.
   Potentially, out-of-band PASSporT delivery could thus improve on the
   privacy story of STIR.

   The principle actors in the operation of out-of-band are the AS, VS,
   and CPS.  The AS and VS functions differ from baseline behavior
   [RFC8224], in that they interact with a CPS over a non-SIP interface,
   of which the REST interface in Section 9 serves as an example.  Some
   out-of-band deployments may also require a discovery service for the
   CPS itself (Section 10) and/or encryption keys (Section 11).  Even
   with encrypted PASSporTs, the network interactions by which the AS
   and VS interact with the CPS, and to a lesser extent any discovery
   services, thus create potential opportunities for data leakage about
   calling and called parties.

   The process of storing and retrieving PASSporTs at a CPS can itself
   reveal information about calls being placed.  The mechanism takes
   care not to require that the AS authenticate itself to the CPS,
   relying instead on a blind signature mechanism for flood control
   prevention.  Section 7.4 discusses the practice of storing "dummy"
   PASSporTs at random intervals to thwart traffic analysis, and as
   Section 8.2 notes, a CPS is required to return a dummy PASSporT even
   if there is no PASSporT indexed for that calling number, which
   similarly enables the retrieval side to randomly request PASSporTs
   when there are no calls in progress.  Note that the caller's IP
   address itself leaks information about the caller.  Proxying the
   storage of the CPS through some third party could help prevent this
   attack.  It might also be possible to use a more sophisticated system
   such as Riposte [RIPOSTE].  These measures can help to mitigate
   information disclosure in the system.  In implementations that
   require service discovery (see Section 10), perhaps through key
   discovery (Section 11), similar measures could be used to make sure
   that service discovery does not itself disclose information about
   calls.

   Ultimately, this document only provides a framework for future
   implementation of out-of-band systems, and the privacy properties of
   a given implementation will depend on architectural assumptions made
   in those environments.  More closed systems for intranet operations
   may adopt a weaker security posture but otherwise mitigate the risks
   of information disclosure, whereas more open environments will
   require careful implementation of the practices described here.

   For general privacy risks associated with the operations of STIR,
   also see the privacy considerations covered in Section 11 of
   [RFC8224].

14.  Security Considerations

   This entire document is about security, but the detailed security
   properties will vary depending on how the framework is applied and
   deployed.  General guidance for dealing with the most obvious
   security challenges posed by this framework is given in Sections 7.3
   and 7.4, along proposed solutions for problems like denial-of-service
   attacks or traffic analysis against the CPS.

   Although there are considerable security challenges associated with
   widespread deployment of a public CPS, those must be weighed against
   the potential usefulness of a service that delivers a STIR assurance
   without requiring the passage of end-to-end SIP.  Ultimately, the
   security properties of this mechanism are at least comparable to in-
   band STIR: the substitution attack documented in Section 7.4 could be
   implemented by any in-band SIP intermediary or eavesdropper who
   happened to see the PASSporT in transit, say, and launched its own
   call with a copy of that PASSporT to race against the original to the
   destination.

15.  Informative References

   [MODERN-TERI]
              Peterson, J., "An Architecture and Information Model for
              Telephone-Related Information (TeRI)", Work in Progress,
              Internet-Draft, draft-ietf-modern-teri-00, 2 July 2018,
              <https://tools.ietf.org/html/draft-ietf-modern-teri-00>.

   [PASSPORT-DIVERT]
              Peterson, J., "PASSporT Extension for Diverted Calls",
              Work in Progress, Internet-Draft, draft-ietf-stir-
              passport-divert-09, 13 July 2020,
              <https://tools.ietf.org/html/draft-ietf-stir-passport-
              divert-09>.

   [PRIVACY-PASS]
              Davidson, A. and N. Sullivan, "The Privacy Pass Protocol",
              Work in Progress, Internet-Draft, draft-privacy-pass-00, 3
              November 2019,
              <https://tools.ietf.org/html/draft-privacy-pass-00>.

   [REST]     Fielding, R., "Architectural Styles and the Design of
              Network-based Software Architectures, Chapter 5:
              Representational State Transfer", Ph.D.
              Dissertation, University of California, Irvine, 2010.

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

   [RFC5636]  Park, S., Park, H., Won, Y., Lee, J., and S. Kent,
              "Traceable Anonymous Certificate", RFC 5636,
              DOI 10.17487/RFC5636, August 2009,
              <https://www.rfc-editor.org/info/rfc5636>.

   [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,
              <https://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, <https://www.rfc-editor.org/info/rfc6940>.

   [RFC6960]  Santesson, S., Myers, M., Ankney, R., Malpani, A.,
              Galperin, S., and C. Adams, "X.509 Internet Public Key
              Infrastructure Online Certificate Status Protocol - OCSP",
              RFC 6960, DOI 10.17487/RFC6960, June 2013,
              <https://www.rfc-editor.org/info/rfc6960>.

   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
              Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
              2014, <https://www.rfc-editor.org/info/rfc7258>.

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

   [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
              for Security", RFC 7748, DOI 10.17487/RFC7748, January
              2016, <https://www.rfc-editor.org/info/rfc7748>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8224]  Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
              "Authenticated Identity Management in the Session
              Initiation Protocol (SIP)", RFC 8224,
              DOI 10.17487/RFC8224, February 2018,
              <https://www.rfc-editor.org/info/rfc8224>.

   [RFC8225]  Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
              Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
              <https://www.rfc-editor.org/info/rfc8225>.

   [RFC8226]  Peterson, J. and S. Turner, "Secure Telephone Identity
              Credentials: Certificates", RFC 8226,
              DOI 10.17487/RFC8226, February 2018,
              <https://www.rfc-editor.org/info/rfc8226>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RIPOSTE]  Corrigan-Gibbs, H., Boneh, D., and D. Mazières, "Riposte:
              An Anonymous Messaging System Handling Millions of Users",
              May 2015, <https://people.csail.mit.edu/henrycg/pubs/
              oakland15riposte/>.

   [TLS-SUBCERTS]
              Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla,
              "Delegated Credentials for TLS", Work in Progress,
              Internet-Draft, draft-ietf-tls-subcerts-10, 24 January
              2021,
              <https://tools.ietf.org/html/draft-ietf-tls-subcerts-10>.

   [VIPR-OVERVIEW]
              Barnes, M., Jennings, C., Rosenberg, J., and M. Petit-
              Huguenin, "Verification Involving PSTN Reachability:
              Requirements and Architecture Overview", Work in Progress,
              Internet-Draft, draft-jennings-vipr-overview-06, 9
              December 2013, <https://tools.ietf.org/html/draft-
              jennings-vipr-overview-06>.

Acknowledgments

   The ideas in this document came out of discussions with Richard
   Barnes and Cullen Jennings.  We'd also like to thank Russ Housley,
   Chris Wendt, Eric Burger, Mary Barnes, Ben Campbell, Ted Huang,
   Jonathan Rosenberg, and Robert Sparks for helpful suggestions.

Authors' Addresses

   Eric Rescorla
   Mozilla

   Email: ekr@rtfm.com


   Jon Peterson
   Neustar, Inc.
   1800 Sutter St Suite 570
   Concord, CA 94520
   United States of America

   Email: jon.peterson@team.neustar