STIR Out-of-Band Architecture and Use Cases
draft-ietf-stir-oob-01
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (stir WG) | |
|---|---|---|---|
| Authors | Eric Rescorla , Jon Peterson | ||
| Last updated | 2017-10-30 | ||
| Replaces | draft-rescorla-stir-fallback | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Formats | plain text htmlized pdfized bibtex | ||
| Reviews |
GENART Telechat review
(of
-06)
Ready with Nits
GENART Last Call review
(of
-05)
Almost Ready
SECDIR Last Call review
(of
-05)
Has Nits
|
||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-stir-oob-01
Network Working Group E. Rescorla
Internet-Draft Mozilla
Intended status: Standards Track J. Peterson
Expires: May 2, 2018 Neustar
October 29, 2017
STIR Out-of-Band Architecture and Use Cases
draft-ietf-stir-oob-01.txt
Abstract
The PASSporT format defines a token that can be carried by signaling
protocols, including SIP, to cryptographically attest the identify of
callers. Not all telephone calls use Internet signaling protocols,
however, and some calls use them for only part of their signaling
path. 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 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 https://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 2, 2018.
Copyright Notice
Copyright (c) 2017 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
Rescorla & Peterson Expires May 2, 2018 [Page 1]
Internet-Draft STIR Fallback October 2017
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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Operating Environments . . . . . . . . . . . . . . . . . . . 4
4. Dataflows . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . 7
5.4. Case 4: Gateway Out-of-band . . . . . . . . . . . . . . . 7
6. Storing and Retrieving PASSporTs . . . . . . . . . . . . . . 8
6.1. Storage . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Retrieval . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Solution Architecture . . . . . . . . . . . . . . . . . . . . 11
7.1. Credentials and Phone Numbers . . . . . . . . . . . . . . 12
7.2. Call Flow . . . . . . . . . . . . . . . . . . . . . . . . 12
7.3. Security Analysis . . . . . . . . . . . . . . . . . . . . 13
7.4. Substitution Attacks . . . . . . . . . . . . . . . . . . 13
8. Call Placement Service Discovery . . . . . . . . . . . . . . 14
9. Credential Lookup . . . . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
12. Security Considerations . . . . . . . . . . . . . . . . . . . 16
13. Informative References . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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
Rescorla & Peterson Expires May 2, 2018 [Page 2]
Internet-Draft STIR Fallback October 2017
from telephone numbers still 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, ...) 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. Even if fields for
tunneling arbtirary 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.
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. Additionally, various kinds of gateways
increasingly front for legacy equipment. 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.
This specification therefore builds on the PASSporT
[I-D.ietf-stir-passport] mechanism and the work of
Rescorla & Peterson Expires May 2, 2018 [Page 3]
Internet-Draft STIR Fallback October 2017
[I-D.ietf-stir-rfc4474bis] to define 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 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].
3. Operating Environments
This section describes the environments 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:
Rescorla & Peterson Expires May 2, 2018 [Page 4]
Internet-Draft STIR Fallback October 2017
+---------+
/ \
+--- +---+
+----------+ +--+ / \ +--+ +----------+
| | | | | 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.
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 9 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 immediately 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 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
Rescorla & Peterson Expires May 2, 2018 [Page 5]
Internet-Draft STIR Fallback October 2017
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.
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.
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 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
Rescorla & Peterson Expires May 2, 2018 [Page 6]
Internet-Draft STIR Fallback October 2017
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, 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 per
[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. 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 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).
Rescorla & Peterson Expires May 2, 2018 [Page 7]
Internet-Draft STIR Fallback October 2017
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. 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 PASSporT is thus a key design decision in
the architecture. Broadly, the architecture described here is one
focused on permitting any entity to store encrypted PASSporTs at the
CPS, indexed under the caller number. PASSporTs will be encrypted
with associated with the called number, so these PASSporTs may also
be retrieved by any entity, as 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 would make the CPS a less
attractive target for pervasive monitoring (see [RFC7258]). Ho
bolster the privacy story, prevent denial-of-service flooding of the
CPS, and to complicate traffic analysis, a few additional mechanisms
are also recommended.
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 [I-D.ietf-stir-certificates].
These credentials provide the most obvious way that a CPS can
authorize the storage and retrieval of PASSporTs. However, as use
cases 3 and 4 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, and 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 acceptible if sufficient
steps are taken to mitigate the privacy risk as described in the next
section.
Furthermore, 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 [I-D.ietf-stir-rfc4474bis] STIR: for in-band, we might
Rescorla & Peterson Expires May 2, 2018 [Page 8]
Internet-Draft STIR Fallback October 2017
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. As a first step, transport-level
security can provide confidentiality from eavesdroppers for both the
storage and retrieval of PASSporTs.
6.1. Storage
For authorizing the storage of PASSporTs, the architecture can permit
some flexibility. Note that in this architecture a CPS has no way to
tell if a PASSporT is valid; it simply conveys encrypted blocks that
it cannot access itself. In that 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.
Note that this architecture requires clients that stores PASSporTs to
have access to a public key associated with the intended called party
to be used to encrypt the PASSporT. Discovering this key requires
some new service that does not exist today; 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
therefore might need to be encrypted with multiple keys in the hopes
that one will be decipherable by the relying party.
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 target number, and thereby prevent that called party
from finding a valid PASSporT for an incoming call buried in a
haystack of fake entries. A CPS must therefore implement 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 ths source and destination of traffic.
In order to do this, we propose the use of "blind signatures". A
sender will initially authenticate to the CPS, and acquire a signed
token for the CPS that will be presented later when storing a
PASSporT. The flow looks as follows:
Rescorla & Peterson Expires May 2, 2018 [Page 9]
Internet-Draft STIR Fallback October 2017
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
gets 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 acqusition 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 more than sixty
seconds. 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. harder to mount
6.2. Retrieval
For retrieval of PASSporTs, this architecture assumes that clients
contact the CPS to send requests of the form:
Rescorla & Peterson Expires May 2, 2018 [Page 10]
Internet-Draft STIR Fallback October 2017
Are there any current PASSporTs for calls destined to
2.222.222.2222?
As all PASSporTs stored at the CPS are encrypted with a key belonging
to the intended destination, then potentially the CPS could 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 provides 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.
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 decrypt all PASSporTs retrieved from the CPS, and may find only
one that is valid.
Note that in call forwarding cases, the difficulties in managing the
relationship between PASSporTs with the diversion extension
[I-D.ietf-stir-passport-divert] become more serious. The originating
authentication service would encrypt the PASSporT with the public key
of the intended destination, but when a call is forwarded, it may go
to a destination that does not possess the corresponding private key.
This requires special behavior on the part of the retargeting entity,
and probably the CPS as well, to accommodate encrypted PASSporTs that
show a secure chain of diversion. A storer could for example notify
the CPS that the divert PASSporT it is storing relates to a specific
PASSporT already in the CPS, but in so doing, the storer will
inevitably reveal more metadata to the CPS.
7. Solution Architecture
In this section, we discuss a strawman 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.
Rescorla & Peterson Expires May 2, 2018 [Page 11]
Internet-Draft STIR Fallback October 2017
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 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
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.
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.111.1111 and Bob has the number +2.222.222.2222.
Alice Call Placement Service Bob
-----------------------------------------------------------------------
Store PASSporT for 2.222.222.2222-->
Call from 1.111.111.1111 --------------------------------------------->
<------------- Retrieve PASSporT(s)
for 2.222.222.2222?
Encrypted PASSporT
-(2.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
stores an encrypted PASSporT on the CPS indexed under Bob's number.
The CPS then awaits retrievals for that 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
PSTN mechanisms for relying a calling party number (i.e., the CIN
field of the 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 (assuming they exist). If such
Rescorla & Peterson Expires May 2, 2018 [Page 12]
Internet-Draft STIR Fallback October 2017
a PASSpoRT exists, and the verification service in Bob's phone
decrypts it using his private key, validates it, then Bob's phone can
then 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:
The attacker wishes to impersonate a target when no call from that
target is in progress.
The attacker wishes to substitute himself for an existing call
setup as described in Section 7.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 7.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. However, that is no different from in-band
[I-D.ietf-stir-rfc4474bis] STIR.
7.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 can try to arrange for a false caller-id value, as
shown below:
Rescorla & Peterson Expires May 2, 2018 [Page 13]
Internet-Draft STIR Fallback October 2017
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.
8. Call Placement Service 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 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
Rescorla & Peterson Expires May 2, 2018 [Page 14]
Internet-Draft STIR Fallback October 2017
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.
Some service discovery possibilities under consideration include the
following:
If a credential lookup service is already available (see
Section 9), the CPS location can also be recorded in the callee's
credentials; an extension to [I-D.ietf-stir-certificates] 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 TeRI
[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.
9. Credential Lookup
In order to encrypt a PASSporT (see Section 6.1), 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
Rescorla & Peterson Expires May 2, 2018 [Page 15]
Internet-Draft STIR Fallback October 2017
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 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.
10. Acknowledgments
The ideas in this document come out of discussions with Richard
Barnes and Cullen Jennings. We'd also like to thank Robert Sparks
for helpful suggestions.
11. IANA Considerations
This memo includes no request to IANA.
12. Security Considerations
This entire document is about security, but the detailed security
properties depend on having a single concrete scheme to analyze.
13. Informative References
[I-D.ietf-stir-certificates]
Peterson, J. and S. Turner, "Secure Telephone Identity
Credentials: Certificates", draft-ietf-stir-
certificates-14 (work in progress), May 2017.
Rescorla & Peterson Expires May 2, 2018 [Page 16]
Internet-Draft STIR Fallback October 2017
[I-D.ietf-stir-passport]
Wendt, C. and J. Peterson, "Personal Assertion Token
(PASSporT)", draft-ietf-stir-passport-11 (work in
progress), February 2017.
[I-D.ietf-stir-passport-divert]
Peterson, J., "PASSporT Extension for Diverted Calls",
draft-ietf-stir-passport-divert-00 (work in progress),
July 2017.
[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-16
(work in progress), February 2017.
[I-D.peterson-modern-teri]
Peterson, J., "An Architecture and Information Model for
Telephone-Related Information (TeRI)", draft-peterson-
modern-teri-03 (work in progress), July 2017.
[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,
<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>.
[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>.
Rescorla & Peterson Expires May 2, 2018 [Page 17]
Internet-Draft STIR Fallback October 2017
[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>.
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 2, 2018 [Page 18]