draft-ietf-stir-oob-00.txt   draft-ietf-stir-oob-01.txt 
Network Working Group E. Rescorla Network Working Group E. Rescorla
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track J. Peterson Intended status: Standards Track J. Peterson
Expires: January 4, 2018 Neustar Expires: May 2, 2018 Neustar
July 3, 2017 October 29, 2017
STIR Out of Band Architecture and Use Cases STIR Out-of-Band Architecture and Use Cases
draft-ietf-stir-oob-00.txt draft-ietf-stir-oob-01.txt
Abstract Abstract
The PASSporT format defines a token that can be carried by signaling The PASSporT format defines a token that can be carried by signaling
protocols, including SIP, to cryptographically attest the identify of protocols, including SIP, to cryptographically attest the identify of
callers. Not all telephone calls use Internet signaling protocols, callers. Not all telephone calls use Internet signaling protocols,
however, and some calls use them for only part of their signaling however, and some calls use them for only part of their signaling
path. This document describes use cases that require the delivery of path. This document describes use cases that require the delivery of
PASSporT objects outside of the signaling path, and defines PASSporT objects outside of the signaling path, and defines
architectures and semantics to provide this functionality. architectures and semantics to provide this functionality.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4, 2018. This Internet-Draft will expire on May 2, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Operating Environments . . . . . . . . . . . . . . . . . . . 4 3. Operating Environments . . . . . . . . . . . . . . . . . . . 4
4. Dataflows . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Dataflows . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Case 1: VoIP to PSTN Call . . . . . . . . . . . . . . . . 6 5.1. Case 1: VoIP to PSTN Call . . . . . . . . . . . . . . . . 6
5.2. Case 2: Two Smart PSTN endpoints . . . . . . . . . . . . 6 5.2. Case 2: Two Smart PSTN endpoints . . . . . . . . . . . . 6
5.3. Case 3: PSTN to VoIP Call . . . . . . . . . . . . . . . . 7 5.3. Case 3: PSTN to VoIP Call . . . . . . . . . . . . . . . . 7
5.4. Case 4: Gateway Out-of-band . . . . . . . . . . . . . . . 7 5.4. Case 4: Gateway Out-of-band . . . . . . . . . . . . . . . 7
6. Authorization for Storing and Retrieving PASSporTs . . . . . 8 6. Storing and Retrieving PASSporTs . . . . . . . . . . . . . . 8
6.1. Storage . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Storage . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Retrieval . . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. Retrieval . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2.1. Authentication . . . . . . . . . . . . . . . . . . . 10 7. Solution Architecture . . . . . . . . . . . . . . . . . . . . 11
6.2.2. Encryption . . . . . . . . . . . . . . . . . . . . . 10
7. Solution Architecture . . . . . . . . . . . . . . . . . . . . 12
7.1. Credentials and Phone Numbers . . . . . . . . . . . . . . 12 7.1. Credentials and Phone Numbers . . . . . . . . . . . . . . 12
7.2. Solution Architecture . . . . . . . . . . . . . . . . . . 12 7.2. Call Flow . . . . . . . . . . . . . . . . . . . . . . . . 12
7.3. Security Analysis . . . . . . . . . . . . . . . . . . . . 13 7.3. Security Analysis . . . . . . . . . . . . . . . . . . . . 13
7.4. Substitution Attacks . . . . . . . . . . . . . . . . . . 14 7.4. Substitution Attacks . . . . . . . . . . . . . . . . . . 13
8. Call Placement Service Discovery . . . . . . . . . . . . . . 15 8. Call Placement Service Discovery . . . . . . . . . . . . . . 14
9. To Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Credential Lookup . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Credential Lookup . . . . . . . . . . . . . . . . . . . . 16 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 12. Security Considerations . . . . . . . . . . . . . . . . . . . 16
12. Security Considerations . . . . . . . . . . . . . . . . . . . 17 13. Informative References . . . . . . . . . . . . . . . . . . . 16
13. Informative References . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The STIR problem statement [RFC7340] describes widespread problems The STIR problem statement [RFC7340] describes widespread problems
enabled by impersonation in the telephone network, including illegal enabled by impersonation in the telephone network, including illegal
robocalling, voicemail hacking, and swatting. As telephone services robocalling, voicemail hacking, and swatting. As telephone services
are increasingly migrating onto the Internet, and using Voice over IP are increasingly migrating onto the Internet, and using Voice over IP
(VoIP) protocols such as SIP [RFC3261], it is necessary for these (VoIP) protocols such as SIP [RFC3261], it is necessary for these
protocols to support stronger identity mechanisms to prevent protocols to support stronger identity mechanisms to prevent
skipping to change at page 5, line 35 skipping to change at page 5, line 35
Because in these operating environments endpoints cannot pass Because in these operating environments endpoints cannot pass
cryptographic information to one another directly through signaling, cryptographic information to one another directly through signaling,
any solution must involve some rendezvous mechanism to allow any solution must involve some rendezvous mechanism to allow
endpoints to communicate. We call this rendezvous service a "call endpoints to communicate. We call this rendezvous service a "call
placement service" (CPS), a service where a record of call placement, placement service" (CPS), a service where a record of call placement,
in this case a PASSporT, can be stored for future retrieval. In in this case a PASSporT, can be stored for future retrieval. In
principle this service could communicate any information, but principle this service could communicate any information, but
minimally we expect it to include a full-form PASSporT that attests 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 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 existence of a PASSporT for a given incoming call as rough validation
of the asserted origin of that call. (See Section 9.1 for of the asserted origin of that call. (See Section 9 for limitations
limitations of this design.) of this design.)
There are roughly two plausible dataflow architectures for the CPS: There are roughly two plausible dataflow architectures for the CPS:
The callee registers with the CPS. When the caller wishes to The callee registers with the CPS. When the caller wishes to
place a call to the callee, it sends the PASSporT to the CPS, place a call to the callee, it sends the PASSporT to the CPS,
which immediately forwards it to the callee. which immediately forwards it to the callee.
The caller stores the PASSporT with the CPS at the time of call The caller stores the PASSporT with the CPS at the time of call
placement. When the callee receives the call, it contacts the CPS placement. When the callee receives the call, it contacts the CPS
and retrieves the PASSporT. and retrieves the PASSporT.
skipping to change at page 8, line 16 skipping to change at page 8, line 16
the IP world. In the former case, perhaps the destination endpoints the IP world. In the former case, perhaps the destination endpoints
queries the CPS to retrieve the PASSporT provisioned by the first queries the CPS to retrieve the PASSporT provisioned by the first
gateway. Or if the call ultimately returns to the IP world, it might 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 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 PASSporT from the CPS and attaches it to the new SIP INVITE it
creates, or it might be the terminating administrative domain's creates, or it might be the terminating administrative domain's
verification service that checks the CPS when an INVITE arrives with verification service that checks the CPS when an INVITE arrives with
no Identity header field. Either way the PASSporT can survive the no Identity header field. Either way the PASSporT can survive the
gap in SIP coverage caused by the PSTN leg of the call. gap in SIP coverage caused by the PSTN leg of the call.
6. Authorization for Storing and Retrieving PASSporTs 6. Storing and Retrieving PASSporTs
The use cases show a variety of entities accessing the CPS to store The use cases show a variety of entities accessing the CPS to store
and retrieve PASSporTs. The question of how the CPS authorizes the and retrieve PASSporTs. The question of how the CPS authorizes the
storage and retrieval of PASSporT is thus a key design decision in storage and retrieval of PASSporT is thus a key design decision in
the architecture. 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 The STIR architecture assumes that service providers and in some
cases end user devices will have credentials suitable for attesting cases end user devices will have credentials suitable for attesting
authority over telephone numbers per [I-D.ietf-stir-certificates]. authority over telephone numbers per [I-D.ietf-stir-certificates].
These credentials provide the most obvious way that a CPS can These credentials provide the most obvious way that a CPS can
authorize the storage and retrieval of PASSporTs. However, as use 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 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 entity storing or retrieving PASSporTs to be an intermediary rather
than a device associated with either the originating or terminating than a device associated with either the originating or terminating
side of a call, and those intermediaries often would not have access side of a call, and those intermediaries often would not have access
to STIR credentials covering the telephone numbers in question. 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.
It is an explicit design goal of this mechanism to minimize the Furthermore, it is an explicit design goal of this mechanism to
potential privacy exposure of using a CPS. Ideally, the out-of-band minimize the potential privacy exposure of using a CPS. Ideally, the
mechanism should not result in a worse privacy situation than in-band out-of-band mechanism should not result in a worse privacy situation
[I-D.ietf-stir-rfc4474bis] STIR: for in-band, we might say that a SIP than in-band [I-D.ietf-stir-rfc4474bis] STIR: for in-band, we might
entity is authorized to receive a PASSporT if it is an intermediate say that a SIP entity is authorized to receive a PASSporT if it is an
or final target of the routing of a SIP request. As the originator intermediate or final target of the routing of a SIP request. As the
of a call cannot necessarily predict the routing path a call will originator of a call cannot necessarily predict the routing path a
follow, an out-of-band mechanism could conceivably even improve on call will follow, an out-of-band mechanism could conceivably even
the privacy story. As a first step, transport-level security can improve on the privacy story. As a first step, transport-level
provide confidentiality from eavesdroppers for both the storage and security can provide confidentiality from eavesdroppers for both the
retrieval of PASSporTs. storage and retrieval of PASSporTs.
6.1. Storage 6.1. Storage
For authorizing the storage of PASSporTs, the architecture can permit For authorizing the storage of PASSporTs, the architecture can permit
some flexibility. A CPS could adopt a policy where it will store any some flexibility. Note that in this architecture a CPS has no way to
valid PASSporT - that is, the CPS could act as a limited verification tell if a PASSporT is valid; it simply conveys encrypted blocks that
service and validate the PASSporT, only storing it if the timestamp it cannot access itself. In that architecture, it does not matter
and signature are valid. In that case, it would not matter whether whether the CPS received a PASSporT from the authentication service
the CPS received a PASSporT from the authentication service that that created it or from an intermediary gateway downstream in the
created it or from an intermediary gateway downstream in the routing routing path as in case 4.
path as in case 4: so long as the PASSporT is valid, it would be
stored.
6.2. Retrieval 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.
For retrieval of PASSporTs, the story is a bit more complicated. However, if literally anyone can store PASSporTs in the CPS, an
Beyond using transport-level security when storing and retrieving attacker could easily flood the CPS with millions of bogus PASSporTs
PASSporTs, the architecture must include some way to constrain access indexed under a target number, and thereby prevent that called party
to the PASSporTs stored at a CPS. How those constraints should from finding a valid PASSporT for an incoming call buried in a
operate depends on the semantics of the request used to retrieve haystack of fake entries. A CPS must therefore implement some sort
PASSporTs. A retrieval request could have one of the following three of traffic control system to prevent flooding. Preferably, this
semantics: should not require authenticating the source, as this will reveal to
the CPS both ths source and destination of traffic.
a) Are there any current PASSporTs for calls originating from In order to do this, we propose the use of "blind signatures". A
1.111.111.1111? 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:
b) Are there any current PASSporTs for calls destined to Sender CPS
2.222.222.2222?
c) Are there any current PASSporTs for calls originating from Authenticate to CPS --------------------->
1.111.111.1111 and destined to 2.222.222.2222? Blinded(K_temp) ------------------------->
<------------- Sign(K_cps, Blinded(K_temp))
[Disconnect]
Each of these three semantics results in very different properties Sign(K_cps, K_temp))
for the architecture. If a CPS permitted just anyone to ask for all Sign(K_temp, E(K_receiver, PASSporT)) --->
PASSporTs that happen to exist for current calls to or from a given
telephone number, that would be an unacceptable privacy situation.
Although on the surface semantic (c) may seem sufficiently strict, a
particular adversary might only be interested in learning when one
specific party calls another, and there are certainly cases in which
that could pose a significant security risk. While a CPS could
eventually refuse to answer repeated requests from a single device
that is obviously polling to collect the state of calls in progress,
more sophisticated adversaries could outwit any attempt to do source
filtering on requests at the CPS.
The semantics of (a) or (b) vs. (c) could be very significant when At an initial time when no call is yet in progress, a potential
the originating and destination numbers are for call centers or client connects to the CPS, authenticates, and sends a blinded
similar organizations that send or receive a vast amount of calls for version of a freshly generated public key. The CPS returns a signed
a single number. In a case where many thousands of people are trying version of that blinded key. The sender can then unblind the key and
to call a number where tickets have just gone on sale, for example, gets a signature on K_temp from the CPS
it might be difficult using semantics (b) to sift through all of the
call setup attempts in progress to find a PASSporT matching any
particular call. A more narrow semantic like (c) would make it far
easier.
Sometimes the more narrow semantics of (c) can pose an obstacle to Then later, when a client wants to store a PASSporT, it connects to
acquiring the right PASSporT, for example in call forwarding cases the CPS anonymously (preferably over a network connection that cannot
where retargeting of the request has occurred. Even using semantic be correlated with the token acquisition) and sends both the signed
(b) would be problematic if the PASSporT stored by the originating K_temp and its own signature over the encrypted PASSporT. The CPS
authentication service had a different original "dest". Mechanisms verifies both signatures and if they verify, stores the encrypted
have been proposed for STIR to patch this by creating PASSporTs that passport (discarding the signatures).
record the diversion (see [I-D.peterson-passport-divert]), and
potentially a CPS could store these additional PASSporT objects and
supply them through the retrieval interface.
If we assume that the party retrieving PASSporTs from the CPS has a This design lets the CPS rate limit how many PASSporTs a given sender
STIR credential attesting authority over the terminating number, then can store just by counting how many times K_temp appears; perhaps CPS
two more attractive mechanisms become possible: using authentication policy might reject storage attempts and require acqusition of a new
and encryption. Note however that in some use cases, like case 3 K_temp after storing more than a certain number of PASSporTs indexed
subcase 1 above, the retrieving party is an intermediary who would under the same destination number in a short interval. This does not
not have access to the necessary credentials. However, this might of course allow the CPS to tell when bogus data is being provisioned
argue that subcase 1 should be disallowed for security reasons, and by an attacker, simply the rate at which data is being provisioned.
only subcase 2 should be permitted. Potentially, feedback mechanisms could be developed that would allow
the called parties to tell the CPS when they are receiving unusual or
bogus PASSporTs.
6.2.1. Authentication 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
For any of the three proposed retrieval semantics, a CPS could 6.2. Retrieval
authenticate a request to retrieve PASSporTs and only release
PASSporTs that have a destination that matches the credential
provided by the requestor. Per semantic (b), if a smart endpoint has
a credential for 2.222.222.2222, it could send a request to the CPS
signed with that credential to retrieve any PASSporTs for calls in
progress to 2.222.222.2222. In this case, (a) and (c) have very
similar semantics: when the requestor asks for (a), effectively they
would receive only those PASSporTs coming from 1.111.111.1111 that
are destined to 2.222.222.2222 - though perhaps in cases where the
call had been forwarded, a CPS aware of the situation could
understand that the new destination should be authorized to see the
original PASSporT.
On balance, an approach along the lines of requiring authenticating For retrieval of PASSporTs, this architecture assumes that clients
requests with semantic (a) appears attractive as a direction for out- contact the CPS to send requests of the form:
of-band.
6.2.2. Encryption Are there any current PASSporTs for calls destined to
2.222.222.2222?
Some of the privacy risks on the retrieval side could potentially be As all PASSporTs stored at the CPS are encrypted with a key belonging
mitigated with encryption. If all PASSporTs stored at a CPS were to the intended destination, then potentially the CPS could allow
encrypted with a key belonging to the intended destination, then anyone to download PASSporTs for a called number without much fear of
potentially the CPS could allow almost anyone to download PASSporTs compromising private information about calls in progress - provided
using semantics (a) or (b) without much fear of compromising private that the CPS always provides at least one encrypted blob in response
information about calls in progress - provided that the CPS always to a request, even if there was no call in progress. Otherwise,
provided at least one encrypted blob in response to a request, even entities could poll the CPS constantly, or eavesdrop on traffic, to
if there was no call in progress. It would also prevent the CPS learn whether or not calls were in progress. The CPS MUST generate
itself from learning the contents of PASSporTs, and thus metadata at least one unique and plausible encrypted response to all retrieval
about calls in progress, which would make the CPS a less attractive requests, and these dummy encrypted PASSporTs MUST NOT be repeated
target for pervasive monitoring (see [RFC7258]). However, encrypting for later calls.
PASSporTs faces some substantial difficulties.
First, this requires the entity that stores the PASSporT to have Because the entity placing a call may discover multiple keys
access to a public key associated with the intended called party to associated with the called party number, multiple valid PASSporTs may
be used to encrypt the PASSporT. Discovering this key would require be stored in the CPS. A particular called party who retrieves
some new service that does not exist today; depending on how the CPS PASSporTs from the CPS may have access to only one of those keys.
is architected, however, some kind of key store or repository could Thus, the presence of one or more PASSporTs that the called party
be implemented adjacent to it, and perhaps even incorporated into its cannot decrypt - which would be indistinguishable from the "dummy"
operation. This key discovery problem is compounded by the fact that PASSporTS created by the CPS when no calls are in progress - does not
there can potentially be multiple entities that have authority over a entail that there is no call in progress. A retriever likely will
telephone number: a carrier, a reseller, an enterprise, and an end need decrypt all PASSporTs retrieved from the CPS, and may find only
user might all have credentials permitting them to attest that they one that is valid.
are allowed to originate calls from a number, say. PASSporTs might
need to be encrypted with multiple keys in the hopes that one will be
decipherable by the relying party.
Second, in call forwarding cases, the difficulties in managing the Note that in call forwarding cases, the difficulties in managing the
relationship between PASSporTs with the diversion extension relationship between PASSporTs with the diversion extension
[I-D.peterson-passport-divert] become more serious. The originating [I-D.ietf-stir-passport-divert] become more serious. The originating
authentication service would encrypt the PASSporT with the public key authentication service would encrypt the PASSporT with the public key
of the intended destination, but when a call is forwarded, it may go of the intended destination, but when a call is forwarded, it may go
to a destination that does not possess the corresponding private key. to a destination that does not possess the corresponding private key.
It would require special behavior on the part of the retargeting This requires special behavior on the part of the retargeting entity,
entity, and probably the CPS as well, to accommodate encrypted and probably the CPS as well, to accommodate encrypted PASSporTs that
PASSporTs that show a secure chain of diversion. A storer could for show a secure chain of diversion. A storer could for example notify
example notify the CPS that the divert PASSporT it is storing relates the CPS that the divert PASSporT it is storing relates to a specific
to a specific PASSporT already in the CPS, but in so doing, the PASSporT already in the CPS, but in so doing, the storer will
storer will inevitably reveal more metadata to the CPS. inevitably reveal more metadata to the CPS.
Another side effect of encrypting PASSporTs before storing them is
that the CPS can no longer validate the PASSporTs since it cannot in
fact read them. However, a CPS needs to know enough about PASSporTs
so that it can respond to requests to retrieve them, whichever
semantics are used - which means the CPS will always process some
amount of metadata (even if some sort of hash function is used to
index PASSporTs). Unless the storer of PASSporTs is authenticated,
it may be possible for attackers to inject bogus PASSporTs into the
system: and an authentication and authorization process in the CPS
again will inevitably help the CPS to collect precisely the data that
encryption is supposed to hide. Moreover, note that merely injecting
a bogus PASSporT into a CPS will not allow attackers to impersonate
parties. That is because verification services trust a PASSporT
based its own internal signature, not based on where the verification
service found it. This is orthogonal to the current question of how
the CPS authorizes an endpoint to acquire a PASSporT; though of
course spamming a CPS with large numbers of bogus PASSporTs could
cause a denial of service or similar problems with retrieval of
PASSporTs.
7. Solution Architecture 7. Solution Architecture
In this section, we discuss a strawman architecture for providing the In this section, we discuss a strawman architecture for providing the
service described in the previous sections. This discussion is service described in the previous sections. This discussion is
deliberately sketchy, focusing on broad concepts and skipping over deliberately sketchy, focusing on broad concepts and skipping over
details. The intent here is merely to provide a rough concept, not a details. The intent here is merely to provide an overall
complete solution. architecture, not an implementable specification.
7.1. Credentials and Phone Numbers 7.1. Credentials and Phone Numbers
We start from the premise of the STIR problem statement [RFC7340] We start from the premise of the STIR problem statement [RFC7340]
that phone numbers can be associated with credentials which can be that phone numbers can be associated with credentials which can be
used to attest ownership of numbers. For purposes of exposition, we used to attest ownership of numbers. For purposes of exposition, we
will assume that ownership is associated with the endpoint (e.g., a will assume that ownership is associated with the endpoint (e.g., a
smartphone) but it might well be associated with a provider or smartphone) but it might well be associated with a provider or
gateway acting for the endpoint instead. It might be the case that gateway acting for the endpoint instead. It might be the case that
multiple entities are able to act for a given number, provided that multiple entities are able to act for a given number, provided that
they have the appropriate authority. [I-D.ietf-stir-certificates] they have the appropriate authority. [I-D.ietf-stir-certificates]
describes a credentials system suitable for this purpose; the describes a credentials system suitable for this purpose; the
question of how an entity is determined to have control of a given question of how an entity is determined to have control of a given
number is out of scope for the current document. number is out of scope for the current document.
7.2. Solution Architecture 7.2. Call Flow
An overview of the basic calling and verification process is shown An overview of the basic calling and verification process is shown
below. In this diagram, we assume that Alice has the number below. In this diagram, we assume that Alice has the number
+1.111.111.1111 and Bob has the number +2.222.222.2222. +1.111.111.1111 and Bob has the number +2.222.222.2222.
Alice Call Placement Service Bob Alice Call Placement Service Bob
----------------------------------------------------------------------- -----------------------------------------------------------------------
Store PASSporT ---------------->
Call from 1.111.111.1111 ----------------------------------------------> Store PASSporT for 2.222.222.2222-->
<- Authenticate as 1.222.222.2222 ----> Call from 1.111.111.1111 --------------------------------------------->
<-------------- Retrieve call record <------------- Retrieve PASSporT(s)
from 1.111.111.1111? for 2.222.222.2222?
(1.222.222.2222,1.111.111.1111) --> Encrypted PASSporT
-(2.222.222.2222,1.111.111.1111)-->
[Ring phone with callerid [Ring phone with callerid
= 1.111.111.1111] = 1.111.111.1111]
When Alice wishes to make a call to Bob, she contacts the CPS and When Alice wishes to make a call to Bob, she contacts the CPS and
stores a PASSporT on the CPS. The CPS validates the PASSporT before stores an encrypted PASSporT on the CPS indexed under Bob's number.
indexing it so that it can be acquired with a request from Bob's The CPS then awaits retrievals for that number.
number
Once Alice has stored the PASSporT, she then places the call to Bob 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 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 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 PSTN mechanisms for relying a calling party number (i.e., the CIN
field of the IAM). Instead, Bob's phone transparently contacts the field of the IAM). Instead, Bob's phone transparently contacts the
CPS, authenticates itself, and requests any current PASSporTs for CPS and requests any current PASSporTs for calls to his number. The
calls from Alice. The CPS responds with any such PASSporTs (assuming CPS responds with any such PASSporTs (assuming they exist). If such
they exist). If such a PASSpoRT exists, and the verification service a PASSpoRT exists, and the verification service in Bob's phone
in Bob's phone validates it, then Bob's phone can then present the decrypts it using his private key, validates it, then Bob's phone can
calling party number information as valid. Otherwise, the call is then present the calling party number information as valid.
unverifiable. Note that this does not necessarily mean that the call Otherwise, the call is unverifiable. Note that this does not
is bogus; because we expect incremental deployment many legitimate necessarily mean that the call is bogus; because we expect
calls will be unverifiable. incremental deployment many legitimate calls will be unverifiable.
7.3. Security Analysis 7.3. Security Analysis
The primary attack we seek to prevent is an attacker convincing the 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 callee that a given call is from some other caller C. There are two
scenarios to be concerned with: scenarios to be concerned with:
The attacker wishes to impersonate a target when no call from that The attacker wishes to impersonate a target when no call from that
target is in progress. target is in progress.
skipping to change at page 15, line 17 skipping to change at page 14, line 41
phone will attempt to verify the attacker's call (and succeed since 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 they are indistinguishable) and the CS's call will go to busy/voice
mail/call waiting. Note: in a SIP environment, the callee might mail/call waiting. Note: in a SIP environment, the callee might
notice that there were multiple INVITEs and thus detect this attack. notice that there were multiple INVITEs and thus detect this attack.
8. Call Placement Service Discovery 8. Call Placement Service Discovery
In order for the two ends of the out-of-band dataflow to coordinate, 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 they must agree on a way to discover a CPS and retrieve PASSporT
objects from it based solely on the rendezvous information available: objects from it based solely on the rendezvous information available:
the calling party number and the called number. There are a number the calling party number and the called number. Because the storage
of potential service discovery mechanisms that could be used for this of PASSporTs in this architecture is indexed by the called party
purpose. The means of service discovery may vary by use case. 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, Although the discussion above is written in terms of a single CPS,
having a significant fraction of all telephone calls result in having a significant fraction of all telephone calls result in
storing and retrieving PASSporTs at a single monolithic CPS has storing and retrieving PASSporTs at a single monolithic CPS has
obvious scaling problems, and would as well allow the CPS to gather obvious scaling problems, and would as well allow the CPS to gather
metadata about a very wide set of callers and callees. These issues metadata about a very wide set of callers and callees. These issues
can be alleviated by operational models with a federated CPS; any can be alleviated by operational models with a federated CPS; any
service discovery mechanism for out-of-band STIR should enable service discovery mechanism for out-of-band STIR should enable
federation of the CPS function. federation of the CPS function.
Some service discovery possibilities under consideration include the Some service discovery possibilities under consideration include the
following: following:
If a credential lookup service is already available, the CPS If a credential lookup service is already available (see
location can also be recorded in the callee's credentials; an Section 9), the CPS location can also be recorded in the callee's
extension to [I-D.ietf-stir-certificates] could for example credentials; an extension to [I-D.ietf-stir-certificates] could
provide a link to the location of the CPS where PASSporTs should for example provide a link to the location of the CPS where
be stored for a destination. PASSporTs should be stored for a destination.
There exist a number of common directory systems that might be There exist a number of common directory systems that might be
used to translate telephone numbers into the URIs of a CPS. ENUM used to translate telephone numbers into the URIs of a CPS. ENUM
[RFC6116] is commonly implemented, though no "golden root" central [RFC6116] is commonly implemented, though no "golden root" central
ENUM administration exists that could be easily reused today to ENUM administration exists that could be easily reused today to
help the endpoints discover a common CPS. Other protocols help the endpoints discover a common CPS. Other protocols
associated with queries for telephone numbers, such as the TeRI associated with queries for telephone numbers, such as the TeRI
[I-D.peterson-modern-teri] protocol, could also serve for this [I-D.peterson-modern-teri] protocol, could also serve for this
application. application.
skipping to change at page 16, line 15 skipping to change at page 15, line 42
for a particular telephone number should be stored. One advantage for a particular telephone number should be stored. One advantage
that the STIR architecture has over VIPR is that it assumes a that the STIR architecture has over VIPR is that it assumes a
credential system that proves authority over telephone numbers; credential system that proves authority over telephone numbers;
those credentials could be used to determine whether or not a CPS those credentials could be used to determine whether or not a CPS
could legitimately claim to be the proper store for a given could legitimately claim to be the proper store for a given
telephone number. telephone number.
Future versions of this specification will identify suitable service Future versions of this specification will identify suitable service
discovery mechanisms for out-of-band STIR. discovery mechanisms for out-of-band STIR.
9. To Do 9. Credential Lookup
Section 4 provides a broad sketch of an approach. In this section,
we consider some areas for additional work. Readers can feel free to
skip this section, as it is not necessary to get the flavor of the
document.
9.1. Credential Lookup
In order to encrypt a PASSporT (see Section 6.2.2), the caller needs In order to encrypt a PASSporT (see Section 6.1), the caller needs
access to the callee's credentials (specifically their public key). access to the callee's credentials (specifically their public key).
This requires some sort of directory/lookup system. This document This requires some sort of directory/lookup system. This document
does not specify any particular scheme, but a list of requirements does not specify any particular scheme, but a list of requirements
would be something like: would be something like:
Obviously, if there is a single central database and the caller and Obviously, if there is a single central database and the caller and
callee each contact it in real time to determine the other's callee each contact it in real time to determine the other's
credentials, then this represents a real privacy risk, as the central credentials, then this represents a real privacy risk, as the central
database learns about each call. A number of mechanisms are database learns about each call. A number of mechanisms are
potentially available to mitigate this: potentially available to mitigate this:
Have endpoints pre-fetch credentials for potential counterparties Have endpoints pre-fetch credentials for potential counterparties
(e.g., their address book or the entire database). (e.g., their address book or the entire database).
Have caching servers in the user's network that proxy their Have caching servers in the user's network that proxy their
fetches and thus conceal the relationship between the user and the fetches and thus conceal the relationship between the user and the
credentials they are fetching. credentials they are fetching.
Clearly, there is a privacy/timeliness tradeoff in that getting Clearly, there is a privacy/timeliness tradeoff in that getting up-
really up-to-date knowledge about credential validity requires to-date knowledge about credential validity requires contacting the
contacting the credential directory in real-time (e.g., via OCSP). credential directory in real-time (e.g., via OCSP). This is somewhat
This is somewhat mitigated for the caller's credentials in that he mitigated for the caller's credentials in that he can get short-term
can get short-term credentials right before placing a call which only credentials right before placing a call which only reveals his
reveals his calling rate, but not who he is calling. Alternately, calling rate, but not who he is calling. Alternately, the CPS can
the CPS can verify the caller's credentials via OCSP, though of verify the caller's credentials via OCSP, though of course this
course this requires the callee to trust the CPS's verification. requires the callee to trust the CPS's verification. This approach
This approach does not work as well for the callee's credentials, but does not work as well for the callee's credentials, but the risk
the risk there is more modest since an attacker would need to both there is more modest since an attacker would need to both have the
have the callee's credentials and regularly poll the database for callee's credentials and regularly poll the database for every
every potential caller. potential caller.
We consider the exact best point in the tradeoff space to be an open We consider the exact best point in the tradeoff space to be an open
issue. issue.
10. Acknowledgments 10. Acknowledgments
The ideas in this document come out of discussions with Richard The ideas in this document come out of discussions with Richard
Barnes and Cullen Jennings. We'd also like to thank Robert Sparks Barnes and Cullen Jennings. We'd also like to thank Robert Sparks
for helpful suggestions. for helpful suggestions.
skipping to change at page 17, line 38 skipping to change at page 17, line 10
[I-D.ietf-stir-certificates] [I-D.ietf-stir-certificates]
Peterson, J. and S. Turner, "Secure Telephone Identity Peterson, J. and S. Turner, "Secure Telephone Identity
Credentials: Certificates", draft-ietf-stir- Credentials: Certificates", draft-ietf-stir-
certificates-14 (work in progress), May 2017. certificates-14 (work in progress), May 2017.
[I-D.ietf-stir-passport] [I-D.ietf-stir-passport]
Wendt, C. and J. Peterson, "Personal Assertion Token Wendt, C. and J. Peterson, "Personal Assertion Token
(PASSporT)", draft-ietf-stir-passport-11 (work in (PASSporT)", draft-ietf-stir-passport-11 (work in
progress), February 2017. 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] [I-D.ietf-stir-rfc4474bis]
Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session "Authenticated Identity Management in the Session
Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16
(work in progress), February 2017. (work in progress), February 2017.
[I-D.peterson-modern-teri] [I-D.peterson-modern-teri]
Peterson, J., "An Architecture and Information Model for Peterson, J., "An Architecture and Information Model for
Telephone-Related Information (TeRI)", draft-peterson- Telephone-Related Information (TeRI)", draft-peterson-
modern-teri-02 (work in progress), October 2016. modern-teri-03 (work in progress), July 2017.
[I-D.peterson-passport-divert]
Peterson, J., "PASSporT Extension for Diverted Calls",
draft-peterson-passport-divert-01 (work in progress), June
2017.
[I-D.rosenberg-dispatch-vipr-overview] [I-D.rosenberg-dispatch-vipr-overview]
Rosenberg, J., Jennings, C., and M. Petit-Huguenin, Rosenberg, J., Jennings, C., and M. Petit-Huguenin,
"Verification Involving PSTN Reachability: Requirements "Verification Involving PSTN Reachability: Requirements
and Architecture Overview", draft-rosenberg-dispatch-vipr- and Architecture Overview", draft-rosenberg-dispatch-vipr-
overview-04 (work in progress), October 2010. overview-04 (work in progress), October 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to
Uniform Resource Identifiers (URI) Dynamic Delegation Uniform Resource Identifiers (URI) Dynamic Delegation
Discovery System (DDDS) Application (ENUM)", RFC 6116, Discovery System (DDDS) Application (ENUM)", RFC 6116,
DOI 10.17487/RFC6116, March 2011, DOI 10.17487/RFC6116, March 2011,
<http://www.rfc-editor.org/info/rfc6116>. <https://www.rfc-editor.org/info/rfc6116>.
[RFC6940] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S., [RFC6940] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S.,
and H. Schulzrinne, "REsource LOcation And Discovery and H. Schulzrinne, "REsource LOcation And Discovery
(RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940, (RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940,
January 2014, <http://www.rfc-editor.org/info/rfc6940>. January 2014, <https://www.rfc-editor.org/info/rfc6940>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <http://www.rfc-editor.org/info/rfc7258>. 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
Telephone Identity Problem Statement and Requirements", Telephone Identity Problem Statement and Requirements",
RFC 7340, DOI 10.17487/RFC7340, September 2014, RFC 7340, DOI 10.17487/RFC7340, September 2014,
<http://www.rfc-editor.org/info/rfc7340>. <https://www.rfc-editor.org/info/rfc7340>.
Authors' Addresses Authors' Addresses
Eric Rescorla Eric Rescorla
Mozilla Mozilla
Email: ekr@rtfm.com Email: ekr@rtfm.com
Jon Peterson Jon Peterson
Neustar, Inc. Neustar, Inc.
1800 Sutter St Suite 570 1800 Sutter St Suite 570
Concord, CA 94520 Concord, CA 94520
US US
Email: jon.peterson@neustar.biz Email: jon.peterson@neustar.biz
 End of changes. 56 change blocks. 
231 lines changed or deleted 207 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/