draft-ietf-stir-oob-03.txt   draft-ietf-stir-oob-04.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 3, 2019 Neustar Expires: September 12, 2019 Neustar
July 2, 2018 March 11, 2019
STIR Out-of-Band Architecture and Use Cases STIR Out-of-Band Architecture and Use Cases
draft-ietf-stir-oob-03.txt draft-ietf-stir-oob-04.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.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 https://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 3, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://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 . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . 8
6. Storing and Retrieving PASSporTs . . . . . . . . . . . . . . 8 5.5. Case 5: Enterprise Call Center . . . . . . . . . . . . . 8
6.1. Storage . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Storing and Retrieving PASSporTs . . . . . . . . . . . . . . 9
6.2. Retrieval . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Storage . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. Retrieval . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Solution Architecture . . . . . . . . . . . . . . . . . . . . 11 7. Solution Architecture . . . . . . . . . . . . . . . . . . . . 11
7.1. Credentials and Phone Numbers . . . . . . . . . . . . . . 12 7.1. Credentials and Phone Numbers . . . . . . . . . . . . . . 12
7.2. Call Flow . . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. Call Flow . . . . . . . . . . . . . . . . . . . . . . . . 12
7.3. Security Analysis . . . . . . . . . . . . . . . . . . . . 13 7.3. Security Analysis . . . . . . . . . . . . . . . . . . . . 13
7.4. Substitution Attacks . . . . . . . . . . . . . . . . . . 13 7.4. Substitution Attacks . . . . . . . . . . . . . . . . . . 13
7.5. Rate Control for CPS Storage . . . . . . . . . . . . . . 14
8. Authentication and Verification Service Behavior for Out-of- 8. Authentication and Verification Service Behavior for Out-of-
Band . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Band . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Authentication Service . . . . . . . . . . . . . . . . . 14 8.1. Authentication Service . . . . . . . . . . . . . . . . . 16
8.2. Verification Service . . . . . . . . . . . . . . . . . . 16 8.2. Verification Service . . . . . . . . . . . . . . . . . . 17
8.3. Gateway Placement Services . . . . . . . . . . . . . . . 17 8.3. Gateway Placement Services . . . . . . . . . . . . . . . 18
9. Example HTTPS Interface to the CPS . . . . . . . . . . . . . 17 9. Example HTTPS Interface to the CPS . . . . . . . . . . . . . 18
10. CPS Discovery . . . . . . . . . . . . . . . . . . . . . . . . 19 10. CPS Discovery . . . . . . . . . . . . . . . . . . . . . . . . 20
11. Credential Lookup . . . . . . . . . . . . . . . . . . . . . . 20 11. Credential Lookup . . . . . . . . . . . . . . . . . . . . . . 21
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
14. Security Considerations . . . . . . . . . . . . . . . . . . . 21 14. Security Considerations . . . . . . . . . . . . . . . . . . . 22
15. Informative References . . . . . . . . . . . . . . . . . . . 21 15. Informative References . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
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
impersonation. For example, [RFC8224] defines an Identity header of impersonation. For example, [RFC8224] defines an Identity header of
SIP requests capable of carrying a PASSporT [RFC8225] object in SIP SIP requests capable of carrying a PASSporT [RFC8225] object in SIP
as a means to cryptographically attest that the originator of a as a means to cryptographically attest that the originator of a
telephone call is authorized to use the calling party number (or, for telephone call is authorized to use the calling party number (or, for
native SIP cases, SIP URI) associated with the originator of the native SIP cases, SIP URI) associated with the originator of the
call. of the request. call.
Not all telephone calls use SIP today, however; and even those that 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 do use SIP do not always carry SIP signaling end-to-end. Most calls
from telephone numbers still traverse the Public Switched Telephone from telephone numbers still traverse the Public Switched Telephone
Network (PSTN) at some point. Broadly, calls fall into one of three Network (PSTN) at some point. Broadly, calls fall into one of three
categories: categories:
1. One or both of the endpoints is actually a PSTN endpoint. 1. One or both of the endpoints is actually a PSTN endpoint.
2. Both of the endpoints are non-PSTN (SIP, Jingle, ...) but the 2. Both of the endpoints are non-PSTN (SIP, Jingle, ...) but the
call transits the PSTN at some point. call transits the PSTN at some point.
skipping to change at page 3, line 30 skipping to change at page 3, line 32
native SIP end-to-end calls). native SIP end-to-end calls).
The first two categories represent the majority of telephone calls The first two categories represent the majority of telephone calls
associated with problems like illegal robocalling: many robocalls associated with problems like illegal robocalling: many robocalls
today originate on the Internet but terminate at PSTN endpoints. today originate on the Internet but terminate at PSTN endpoints.
However, the core network elements that operate the PSTN are legacy However, the core network elements that operate the PSTN are legacy
devices that are unlikely to be upgradable at this point to support devices that are unlikely to be upgradable at this point to support
an in-band authentication system. As such, those devices largely an in-band authentication system. As such, those devices largely
cannot be modified to pass signatures originating on the Internet--or cannot be modified to pass signatures originating on the Internet--or
indeed any inband signaling data--intact. Even if fields for indeed any inband signaling data--intact. Even if fields for
tunneling arbtirary data can be found in traditional PSTN signaling, tunneling arbitrary data can be found in traditional PSTN signaling,
in some cases legacy elements would strip the signatures from those in some cases legacy elements would strip the signatures from those
fields; in others, they might damage them to the point where they fields; in others, they might damage them to the point where they
cannot be verified. For those first two categories above, any in- cannot be verified. For those first two categories above, any in-
band authentication scheme does not seem practical in the current band authentication scheme does not seem practical in the current
environment. environment.
But while the core network of the PSTN remains fixed, the endpoints But while the core network of the PSTN remains fixed, the endpoints
of the telephone network are becoming increasingly programmable and of the telephone network are becoming increasingly programmable and
sophisticated. Landline "plain old telephone service" deployments, sophisticated. Landline "plain old telephone service" deployments,
especially in the developed world, are shrinking, and increasingly especially in the developed world, are shrinking, and increasingly
being replaced by three classes of intelligent devices: smart phones, being replaced by three classes of intelligent devices: smart phones,
IP PBXs, and terminal adapters. All three are general purpose IP PBXs, and terminal adapters. All three are general purpose
computers, and typically all three have Internet access as well as computers, and typically all three have Internet access as well as
access to the PSTN. Additionally, various kinds of gateways access to the PSTN. Additionally, various kinds of gateways
increasingly front for legacy equipment. All of this provides a increasingly front for deployments of legacy PBX and PSTN switches.
potential avenue for building an authentication system that All of this provides a potential avenue for building an
implements stronger identity while leaving PSTN systems intact. authentication system that implements stronger identity while leaving
PSTN systems intact.
This capability also provides an ideal transitional technology while This capability also provides an ideal transitional technology while
in-band STIR adoption is ramping up. It permits early adopters to in-band STIR adoption is ramping up. It permits early adopters to
use the technology even when intervening network elements are not yet use the technology even when intervening network elements are not yet
STIR-aware, and through various kinds of gateways it may allow STIR-aware, and through various kinds of gateways, it may allow
providers with a significant PSTN investment to still secure their providers with a significant PSTN investment to still secure their
calls with STIR. calls with STIR.
This specification therefore builds on the PASSporT [RFC8225] This specification therefore builds on the PASSporT [RFC8225]
mechanism and the work of [RFC8224] to define a way that a PASSporT mechanism and the work of [RFC8224] to define a way that a PASSporT
object created in the originating network of a call can reach the 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 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 in the call signaling. This relies on a new service defined in this
document that permits the PASSporT object to be stored during call document called a Call Placement Service (CPS) that permits the
processing and retrieved for verification purposes. PASSporT object to be stored during call processing and retrieved for
verification purposes.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 2119 [RFC2119].
3. Operating Environments 3. Operating Environments
This section describes the environments in which the proposed This section describes the environments in which the proposed out-of-
mechanism is intended to operate. In the simplest setting, Alice is band STIR mechanism is intended to operate. In the simplest setting,
calling Bob through some set of gateways and/or the PSTN. Both Alice Alice is calling Bob through some set of gateways and/or the PSTN.
and Bob have smart devices which can be modified, but they do not Both Alice and Bob have smart devices which can be modified, but they
have a clear connection between them: Alice cannot inject any data do not have a clear connection between them: Alice cannot inject any
into signaling which Bob can read, with the exception of the asserted data into signaling which Bob can read, with the exception of the
destination and origination E.164 numbers. The calling party number asserted destination and origination E.164 numbers. The calling
might originate from her own device or from the network. These party number might originate from her own device or from the network.
numbers are effectively the only data that can be used for These numbers are effectively the only data that can be used for
coordination between the endpoints. coordination between the endpoints.
+---------+ +---------+
/ \ / \
+--- +---+ +--- +---+
+----------+ / \ +----------+ +----------+ / \ +----------+
| | | Gateways | | | | | | Gateways | | |
| Alice |<----->| and/or |<----->| Bob | | Alice |<----->| and/or |<----->| Bob |
| (caller) | | PSTN | | (callee) | | (caller) | | PSTN | | (callee) |
+----------+ \ / +----------+ +----------+ \ / +----------+
skipping to change at page 5, line 38 skipping to change at page 5, line 43
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 11 for limitations of the asserted origin of that call. (See Section 11 for limitations
of this design.) 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 CPSs could be run by a carrier, as repositories for PASSporTs
for calls sent to its customers, or a CPS could be built-in to an
enterprise PBX, or even a smartphone. To the degree possible, it is
here specified generically, as an idea that may have applicability to
a variety of STIR deployments.
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 6, line 10 skipping to change at page 6, line 24
protocols, it shares their drawbacks. Specifically, the callee must protocols, it shares their drawbacks. Specifically, the callee must
maintain a full-time connection to the CPS to serve as a notification maintain a full-time connection to the CPS to serve as a notification
channel. This comes with the usual networking costs to the callee channel. This comes with the usual networking costs to the callee
and is especially problematic for mobile endpoints. Indeed, if the and is especially problematic for mobile endpoints. Indeed, if the
endpoints had the capabilities to implement such an architecture, endpoints had the capabilities to implement such an architecture,
they could surely just use SIP or some other protocol to set up a 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 secure session; even if the media were going through the traditional
PSTN, a "shadow" SIP session could convey the PASSporT. Thus, we PSTN, a "shadow" SIP session could convey the PASSporT. Thus, we
focus on the second architecture in which the PSTN incoming call focus on the second architecture in which the PSTN incoming call
serves as the notification channel and the callee can then contact serves as the notification channel and the callee can then contact
the CPS to retrieve the PASSporT. the CPS to retrieve the PASSporT. In some 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 5. Use Cases
The following are the motivating use cases for this mechanism. Bear The following are the motivating use cases for this mechanism. Bear
in mind that just as in [RFC8224] there may be multiple Identity in mind that just as in [RFC8224] there may be multiple Identity
headers in a single SIP INVITE, so there may be multiple PASSporTs in headers in a single SIP INVITE, so there may be multiple PASSporTs in
this out-of-band mechanism associated with a single call. For 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 example, a SIP user agent might create a PASSporT for a call with an
end user credential, and as the call exits the originating end user credential, and as the call exits the originating
administrative domain the network authentication service might create administrative domain the network authentication service might create
skipping to change at page 8, line 13 skipping to change at page 8, line 32
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.
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. 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 calls from the originating number has arrived.
6. 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. Broadly, the architecture described here is one the architecture. The STIR architecture assumes that service
focused on permitting any entity to store encrypted PASSporTs at the providers and in some cases end user devices will have credentials
CPS, indexed under the caller number. PASSporTs will be encrypted suitable for attesting authority over telephone numbers per
with associated with the called number, so these PASSporTs may also [RFC8226]. These credentials provide the most obvious way that a CPS
be retrieved by any entity, as only holders of the corresponding can authorize the storage and retrieval of PASSporTs. However, as
private key will be able to decrypt the PASSporT. This also prevents use cases 3 and 4 in Section 5 show, it may sometimes make sense for
the CPS itself from learning the contents of PASSporTs, and thus the entity storing or retrieving PASSporTs to be an intermediary
metadata about calls in progress, which would make the CPS a less rather than a device associated with either the originating or
attractive target for pervasive monitoring (see [RFC7258]). Ho terminating side of a call, and those intermediaries often would not
bolster the privacy story, prevent denial-of-service flooding of the have access to STIR credentials covering the telephone numbers in
CPS, and to complicate traffic analysis, a few additional mechanisms question. Requiring authorization based on a credential to store
are also recommended. PASSporTs is therefore undesirable, though potentially acceptable if
sufficient steps are taken to mitigate any privacy risk of leaking
data.
The STIR architecture assumes that service providers and in some It is an explicit design goal of this mechanism to minimize the
cases end user devices will have credentials suitable for attesting potential privacy exposure of using a CPS. Ideally, the out-of-band
authority over telephone numbers per [RFC8226]. These credentials mechanism should not result in a worse privacy situation than in-band
provide the most obvious way that a CPS can authorize the storage and [RFC8224] STIR: for in-band, we might say that a SIP entity is
retrieval of PASSporTs. However, as use cases 3 and 4 in Section 5 authorized to receive a PASSporT if it is an intermediate or final
show, it may sometimes make sense for the entity storing or target of the routing of a SIP request. As the originator of a call
retrieving PASSporTs to be an intermediary rather than a device cannot necessarily predict the routing path a call will follow, an
associated with either the originating or terminating side of a call, out-of-band mechanism could conceivably even improve on the privacy
and those intermediaries often would not have access to STIR story.
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 Broadly, the architecture recommended here thus is one focused on
minimize the potential privacy exposure of using a CPS. Ideally, the permitting any entity to store encrypted PASSporTs at the CPS,
out-of-band mechanism should not result in a worse privacy situation indexed under the called number. PASSporTs will be encrypted with
than in-band [RFC8224] STIR: for in-band, we might say that a SIP the public key associated with the called number, so these PASSporTs
entity is authorized to receive a PASSporT if it is an intermediate may safely be retrieved by any entity, as only holders of the
or final target of the routing of a SIP request. As the originator corresponding private key will be able to decrypt the PASSporT. This
of a call cannot necessarily predict the routing path a call will also prevents the CPS itself from learning the contents of PASSporTs,
follow, an out-of-band mechanism could conceivably even improve on and thus metadata about calls in progress, which makes the CPS a less
the privacy story. As a first step, transport-level security can attractive target for pervasive monitoring (see [RFC7258]). As a
provide confidentiality from eavesdroppers for both the storage and first step, transport-level security can provide confidentiality from
retrieval of PASSporTs. eavesdroppers for both the storage and retrieval of PASSporTs. To
bolster the privacy story, prevent denial-of-service flooding of the
CPS, and to complicate traffic analysis, a few additional mechanisms
are also recommended below.
6.1. Storage 6.1. Storage
For authorizing the storage of PASSporTs, the architecture can permit There are a few dimensions to authorizing the storage of PASSporTs.
some flexibility. Note that in this architecture a CPS has no way to Encrypting PASSporTs prior to storage entails that a CPS has no way
tell if a PASSporT is valid; it simply conveys encrypted blocks that to tell if a PASSporT is valid; it simply conveys encrypted blocks
it cannot access itself. In that architecture, it does not matter that it cannot access itself, and can make no authorization decision
whether the CPS received a PASSporT from the authentication service based on the PASSporT contents. There is certainly no prospect for
that created it or from an intermediary gateway downstream in the the CPS to verify the PASSporTs itself.
routing path as in case 4.
Note that this architecture requires clients that stores PASSporTs to Note that this architecture requires clients that store PASSporTs to
have access to a public key associated with the intended called party have access to a public key associated with the intended called party
to be used to encrypt the PASSporT. Discovering this key requires to be used to encrypt the PASSporT. Discovering this key requires
some new service that does not exist today; depending on how the CPS the existence of a key lookup service; depending on how the CPS is
is architected, however, some kind of key store or repository could architected, however, some kind of key store or repository could be
be implemented adjacent to it, and perhaps even incorporated into its implemented adjacent to it, and perhaps even incorporated into its
operation. Key discovery is made more complicated by the fact that operation. Key discovery is made more complicated by the fact that
there can potentially be multiple entities that have authority over a there can potentially be multiple entities that have authority over a
telephone number: a carrier, a reseller, an enterprise, and an end telephone number: a carrier, a reseller, an enterprise, and an end
user might all have credentials permitting them to attest that they user might all have credentials permitting them to attest that they
are allowed to originate calls from a number, say. PASSporTs are allowed to originate calls from a number, say. PASSporTs for
therefore might need to be encrypted with multiple keys in the hopes out-of-band use therefore might need to be encrypted with multiple
that one will be decipherable by the relying party. 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:
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 Again, the most obviously way to authorize storage is to require the
can store just by counting how many times K_temp appears; perhaps CPS originator to authenticate themselves to the CPS with their STIR
policy might reject storage attempts and require acqusition of a new credential. However, since the call is indexed at the CPS under the
K_temp after storing more than a certain number of PASSporTs indexed called number, this can weaken the privacy story of the architecture,
under the same destination number in a short interval. This does not as it reveals to the CPS both the identity of the caller and the
of course allow the CPS to tell when bogus data is being provisioned callee. Moreover, it does not work for the gateway use cases
by an attacker, simply the rate at which data is being provisioned. described above; to support those use cases, we must effectively
Potentially, feedback mechanisms could be developed that would allow allow any entity to store PASSporTs at a CPS. This does not degrade
the called parties to tell the CPS when they are receiving unusual or the anti-impersonation security of STIR, because entities who do not
bogus PASSporTs. 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.
This architecture also assumes that the CPS will age out PASSporTs. The solution architecture must therefore include some sort of traffic
A CPS SHOULD NOT keep any stored PASSporT for more than sixty control system to prevent flooding. Preferably, this should not
seconds. Any reduction in this window makes substitution attacks require authenticating the source, as this will reveal to the CPS
(see Section 7.4) harder to mount, but making the window too small both the source and destination of traffic. A potential solution is
might conceivably age PASSporTs out while a heavily redirected call discussed below in Section 7.5.
is still alerting. harder to mount
6.2. Retrieval 6.2. Retrieval
For retrieval of PASSporTs, this architecture assumes that clients For retrieval of PASSporTs, this architecture assumes that clients
contact the CPS to send requests of the form: will contact the CPS through some sort of polling or notification
interface to receive all current PASSporTs for calls destined to a
Are there any current PASSporTs for calls destined to particular telephone number, or block of numbers.
2.222.222.2222?
As all PASSporTs stored at the CPS are encrypted with a key belonging As PASSporTs stored at the CPS are encrypted with a key belonging to
to the intended destination, then potentially the CPS could allow the intended destination, the CPS can safely allow anyone to download
anyone to download PASSporTs for a called number without much fear of PASSporTs for a called number without much fear of compromising
compromising private information about calls in progress - provided private information about calls in progress - provided that the CPS
that the CPS always provides at least one encrypted blob in response always returns at least one encrypted blob in response to a request,
to a request, even if there was no call in progress. Otherwise, even if there was no call in progress. Otherwise, entities could
entities could poll the CPS constantly, or eavesdrop on traffic, to poll the CPS constantly, or eavesdrop on traffic, to learn whether or
learn whether or not calls were in progress. The CPS MUST generate not calls were in progress. The CPS MUST generate at least one
at least one unique and plausible encrypted response to all retrieval unique and plausible encrypted response to all retrieval requests,
requests, and these dummy encrypted PASSporTs MUST NOT be repeated and these dummy encrypted PASSporTs MUST NOT be repeated for later
for later calls. calls.
Because the entity placing a call may discover multiple keys Because the entity placing a call may discover multiple keys
associated with the called party number, multiple valid PASSporTs may associated with the called party number, multiple valid PASSporTs may
be stored in the CPS. A particular called party who retrieves be stored in the CPS. A particular called party who retrieves
PASSporTs from the CPS may have access to only one of those keys. 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 Thus, the presence of one or more PASSporTs that the called party
cannot decrypt - which would be indistinguishable from the "dummy" cannot decrypt - which would be indistinguishable from the "dummy"
PASSporTS created by the CPS when no calls are in progress - does not 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 entail that there is no call in progress. A retriever likely will
need decrypt all PASSporTs retrieved from the CPS, and may find only need decrypt all PASSporTs retrieved from the CPS, and may find only
skipping to change at page 11, line 40 skipping to change at page 11, line 44
Note that in out-of-band call forwarding cases, special behavior is Note that in out-of-band call forwarding cases, special behavior is
required to manage the relationship between PASSporTs using the required to manage the relationship between PASSporTs using the
diversion extension [I-D.ietf-stir-passport-divert]. The originating diversion extension [I-D.ietf-stir-passport-divert]. The originating
authentication service would encrypt the initial PASSporT with the authentication service would encrypt the initial PASSporT with the
public key of the intended destination, but once a call is forwarded, public key of the intended destination, but once a call is forwarded,
it may go to a destination that does not possess the corresponding it may go to a destination that does not possess the corresponding
private key and thus could not decrypt the original PASSporT. This private key and thus could not decrypt the original PASSporT. This
requires the retargeting entity to generated encrypted PASSporTs that requires the retargeting entity to generated encrypted PASSporTs that
show a secure chain of diversion: a retargeting storer SHOULD use the show a secure chain of diversion: a retargeting storer SHOULD use the
"opt" extension to "div" specified in [I-D.ietf-stir-passport-divert] "div-o" PASSporT type, with its "opt" extension, as specified in
in order to nest the original PASSporT within the encrypted diversion [I-D.ietf-stir-passport-divert] in order to nest the original
PASSporT. PASSporT within the encrypted diversion PASSporT.
7. Solution Architecture 7. Solution Architecture
In this section, we discuss a high-level architecture for providing In this section, we discuss a high-level architecture for providing
the service described in the previous sections. This discussion is the 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 an overall details. The intent here is merely to provide an overall
architecture, not an implementable specification. A more concrete architecture, not an implementable specification. A more concrete
example of how this might be specified is given in Section 9. example of how this might be specified is given in Section 9.
skipping to change at page 13, line 4 skipping to change at page 13, line 8
stores an encrypted PASSporT on the CPS indexed under Bob's number. stores an encrypted PASSporT on the CPS indexed under Bob's number.
The CPS then awaits retrievals for that number. The CPS then awaits retrievals for that 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 and requests any current PASSporTs for calls to his number. The CPS and requests any current PASSporTs for calls to his number. The
CPS responds with any such PASSporTs (assuming they exist). If such CPS responds with any such PASSporTs (assuming they exist). If such
a PASSpoRT exists, and the verification service in Bob's phone a PASSporT exists, and the verification service in Bob's phone
decrypts it using his private key, validates it, then Bob's phone can decrypts it using his private key, validates it, then Bob's phone can
then present the calling party number information as valid. present the calling party number information as valid. Otherwise,
Otherwise, the call is unverifiable. Note that this does not the call is unverifiable. Note that this does not necessarily mean
necessarily mean that the call is bogus; because we expect that the call is bogus; because we expect incremental deployment,
incremental deployment many legitimate calls will be unverifiable. 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.
The attacker wishes to substitute himself for an existing call The attacker wishes to substitute himself for an existing call
setup as described in Section 7.4. setup as described in Section 7.4.
If an attacker can inject fake PASSporT into the CPS or in the 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. communication from the CPS to the callee, he can mount either attack.
As PASSporTs should be digitally signed by an appropriate authority As PASSporTs should be digitally signed by an appropriate authority
for the number and verified by the callee (see Section 7.1), this for the number and verified by the callee (see Section 7.1), this
should not arise in ordinary operations. For privacy and robustness should not arise in ordinary operations. For privacy and robustness
reasons, using TLS on the originating side when storing the PASSporT reasons, using TLS on the originating side when storing the PASSporT
at the CPS is recommended. at the CPS is RECOMMENDED.
The entire system depends on the security of the credential The entire system depends on the security of the credential
infrastructure. If the authentication credentials for a given number infrastructure. If the authentication credentials for a given number
are compromised, then an attacker can impersonate calls from that are compromised, then an attacker can impersonate calls from that
number. However, that is no different from in-band [RFC8224] STIR. number. However, that is no different from in-band [RFC8224] STIR.
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 7.4. Substitution Attacks
All that receipt of the PASSporT from the CPS proves to the called 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 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 recently) - it does not prove that any particular incoming call is
from Alice. Consider the scenario in which we have a service which from Alice. Consider the scenario in which we have a service which
provides an automatic callback to a user-provided number. In 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 case, the attacker can try to arrange for a false caller-id value, as
shown below: shown below:
skipping to change at page 14, line 36 skipping to change at page 14, line 38
insert an appropriate PASSporT and then initiates a call to Bob. insert an appropriate PASSporT and then initiates a call to Bob.
Because it is a valid CS injecting the PASSporT, none of the security Because it is a valid CS injecting the PASSporT, none of the security
checks mentioned above help. However, the attacker simultaneously checks mentioned above help. However, the attacker simultaneously
initiates a call to Bob using forged caller-id information 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 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 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.
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". 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
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 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 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.
8. Authentication and Verification Service Behavior for Out-of-Band 8. Authentication and Verification Service Behavior for Out-of-Band
[RFC8224] defines an authentication service and a verification [RFC8224] defines an authentication service and a verification
service as functions that act in the context of SIP requests and service as functions that act in the context of SIP requests and
responses. This specification thus provides a more generic responses. This specification thus provides a more generic
description of authentication service and verification service description of authentication service and verification service
behavior that might or might not involve any SIP transactions, but behavior that might or might not involve any SIP transactions, but
depends only on placing a request for communications from an depends only on placing a request for communications from an
originating identity to one or more destination identities. originating identity to one or more destination identities.
skipping to change at page 15, line 18 skipping to change at page 16, line 26
PASSporT. It can do so only if it possesses the private key of one 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 or more credentials that can be used to sign for that identity, be it
a domain or a telephone number or something other identifier. For a domain or a telephone number or something other identifier. For
example, the authentication service could hold the private key example, the authentication service could hold the private key
associated with a STIR certificate [RFC8225]. associated with a STIR certificate [RFC8225].
Step 2: The authentication service MUST determine that the originator Step 2: The authentication service MUST determine that the originator
of communications can claim the originating identity. This is a of communications can claim the originating identity. This is a
policy decision made by the authentication service that depends on policy decision made by the authentication service that depends on
its relationship to the originator. For an out-of-band application its relationship to the originator. For an out-of-band application
built in to the calling device, for example, this is the same check built-in to the calling device, for example, this is the same check
performed in Step 1: does the calling device have a private key, such performed in Step 1: does the calling device hold a private key, one
one corresponding to a STIR certificate, that can sign for the corresponding to a STIR certificate, that can sign for the
originating identity? originating identity?
Step 3: The authentication service MUST acquire the public key of the Step 3: The authentication service MUST acquire the public key of the
destination, which will be used to encrypt the PASSporT. It must destination, which will be used to encrypt the PASSporT. It MUST
also discover (see Section 10) the CPS associated with the also discover (see Section 10) the CPS associated with the
destination. The authentication service may already have the key and destination. The authentication service may already have the key and
destination CPS cached, or may need to query a service to acquire the destination CPS cached, or may need to query a service to acquire the
key. Note that per Section 6.1 the authentication service may also 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 need to acquire a token for PASSporT storage from the CPS upon CPS
discovery. It is anticipated that the discovery mechanism (see discovery. It is anticipated that the discovery mechanism (see
Section 10) used to find the appropriate CPS will also find the Section 10) used to find the appropriate CPS will also find the
proper key server for the public key of the destination. In some proper key server for the public key of the destination. In some
cases, a destination may have multiple public keys associated with cases, a destination may have multiple public keys associated with
it. In that case, the authentication service MUST collect all of it. In that case, the authentication service MUST collect all of
those keys. those keys.
Step 4: The authentication service MUST create the PASSporT object. Step 4: The authentication service MUST create the PASSporT object.
This includes acquiring the system time to populate the "iat" claim, This includes acquiring the system time to populate the "iat" claim,
and populating the "orig" and "dest" claims as described in and populating the "orig" and "dest" claims as described in
[RFC8225]. The authentication service MUST then encrypt the [RFC8225]. The authentication service MUST then encrypt the
PASSporT. If in Step 3 the authentication service discovered PASSporT. If in Step 3 the authentication service discovered
multiple public keys for the destination, it MUST create one multiple public keys for the destination, it MUST create one
encrypted copy for each public key it discovered. encrypted copy for each public key it discovered.
Finally, the authentication service stores the encrypted PASSporT(s) Finally, the authentication service stores the encrypted PASSporT(s)
at the CPS discovered in Step 3. Only after that is completed should at the CPS discovered in Step 3. Only after that is completed should
any call initiated. Note that a call might be initiated over SIP, any call be initiated. Note that a call might be initiated over SIP,
and the authentication service would place the same PASSporT in the and the authentication service would place the same PASSporT in the
Identity header field value of the SIP request - though SIP would Identity header field value of the SIP request - though SIP would
carry cleartext version rather than an encrypted version sent to the carry cleartext version rather than an encrypted version sent to the
CPS. In that case, out-of-band would serve as a fallback mechanism CPS. In that case, out-of-band would serve as a fallback mechanism
in case the request was not conveyed over SIP end-to-end. Also, note in case the request was not conveyed over SIP end-to-end. Also, note
that the authentication service MAY use a compact form of the that the authentication service MAY use a compact form of the
PASSporT for a SIP request, whereas the version stored at the CPS PASSporT for a SIP request, whereas the version stored at the CPS
MUST always be a full form PASSporT. MUST always be a full form PASSporT.
8.2. Verification Service 8.2. Verification Service
When a call arrives, an out-of-band verification service performs When a call arrives, an out-of-band verification service performs
steps similar to those defined in [RFC8224] with some exceptions: steps similar to those defined in [RFC8224] with some exceptions:
Step 1: The verification service contacts the CPS and requests all Step 1: The verification service contacts the CPS and requests all
current PASSporTs for its destination number. The verification current PASSporTs for its destination number; or alternatively it may
service MUST then decrypt all PASSporTs using its private key. Some receive PASSporTs through a push interface from the CPS in some
PASSporTs may not be decryptable for any number of reasons: they may deployments. The verification service MUST then decrypt all
be intended for a different verification service, or they may be PASSporTs using its private key. Some PASSporTs may not be
"dummy" values inserted by the CPS for privacy purposes. The next decryptable for any number of reasons: they may be intended for a
few steps will narrow down the set of PASSporTs that the verification different verification service, or they may be "dummy" values
service will examine from that initial decryptable set. 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" Step 2: The verification service MUST determine if any "ppt"
extensions in the PASSporTs are unsupported. It takes only the set extensions in the PASSporTs are unsupported. It takes only the set
of supported PASSporTs and applies the next step to them. of supported PASSporTs and applies the next step to them.
Step 3: The verification service MUST determine if there is an Step 3: The verification service MUST determine if there is an
overlap between the called party number number presented in call overlap between the calling party number number presented in call
signaling and the "orig" field of any decrypted PASSporTs. It takes signaling and the "orig" field of any decrypted PASSporTs. It takes
the set of matching PASSporTs and applies the next step to them. the set of matching PASSporTs and applies the next step to them.
Step 4: The verification service MUST determine if the credentials Step 4: The verification service MUST determine if the credentials
that signed each PASSporT are valid, and if the verification service that signed each PASSporT are valid, and if the verification service
trusts the CA that issued the credentials. It takes the set of trusts the CA that issued the credentials. It takes the set of
trusted PASSporTs to the next step. trusted PASSporTs to the next step.
Step 5: The verification service MUST check the freshness of the Step 5: The verification service MUST check the freshness of the
"iat" claim of each PASSporT. The exact interval of time that "iat" claim of each PASSporT. The exact interval of time that
determines freshness is left to local policy. It takes the set of determines freshness is left to local policy. It takes the set of
fresh PASSporTs to the next step. fresh PASSporTs to the next step.
Step 6: The verification service MUST check the validity of the Step 6: The verification service MUST check the validity of the
signature over each PASSporT, as described in described in [RFC8225]. signature over each PASSporT, as described in [RFC8225].
Finally, the verification service will end up with one or more valid Finally, the verification service will end up with one or more valid
PASSporTs corresponding to the call it has received. This document PASSporTs corresponding to the call it has received. This document
does not prescribe any particular treatment of calls that have valid does not prescribe any particular treatment of calls that have valid
PASSporTs associated with them. The handling of the message after PASSporTs associated with them. The handling of the message after
the verification process depends on how the verification service is the verification process depends on how the verification service is
implemented and on local policy. However, it is anticipated that implemented and on local policy. However, it is anticipated that
local policies could involve making different forwarding decisions in local policies could involve making different forwarding decisions in
intermediary implementations, or changing how the user is alerted or intermediary implementations, or changing how the user is alerted or
how identity is rendered in UA implementations. how identity is rendered in UA implementations.
8.3. Gateway Placement Services 8.3. Gateway Placement Services
The out-of-band mechanism also supports the presence of gateway The STIR out-of-band mechanism also supports the presence of gateway
placement services, which do not create PASSporTs themselves, but placement services, which do not create PASSporTs themselves, but
instead take PASSporTs out of signaling protocols and store them at a instead take PASSporTs out of signaling protocols and store them at a
CPS before gatewaying to a protocol that cannot carry PASSporTs CPS before gatewaying to a protocol that cannot carry PASSporTs
itself. For example, a SIP gateway that sends calls to the PSTN itself. For example, a SIP gateway that sends calls to the PSTN
could receive a call with an Identity header, extract a PASSporT from could receive a call with an Identity header, extract a PASSporT from
the Identity header, and store that PASSporT at a CPS. the Identity header, and store that PASSporT at a CPS.
To place a PASSporT at a CPS, a gateway MUST perform Step 3 of 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 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 associated with the destination of the call, and may need to acquire
skipping to change at page 17, line 32 skipping to change at page 18, line 43
band PASSporT(s) from the in-band signaling, encrypts the band PASSporT(s) from the in-band signaling, encrypts the
PASSporT(s), and stores them at the CPS. PASSporT(s), and stores them at the CPS.
A similar service could be performed by a gateway that retrieves A similar service could be performed by a gateway that retrieves
PASSporTs from a CPS and inserts them into signaling protocols that PASSporTs from a CPS and inserts them into signaling protocols that
support carrying PASSporTS in-band. This behavior may be defined by support carrying PASSporTS in-band. This behavior may be defined by
future specifications. future specifications.
9. Example HTTPS Interface to the CPS 9. Example HTTPS Interface to the CPS
As an rough example, we should a Call Placement Service As an rough example, we show a Call Placement Service implementation
implementation here which uses a REST API to store and retrieve here which uses a REST API to store and retrieve objects at the CPS.
objects at the CPS. The calling party stores the PASSporT at the CPS The calling party stores the PASSporT at the CPS prior to initiating
prior to initiating the call; the PASSporT is stored at a location at the call; the PASSporT is stored at a location at the CPS that
the CPS that corresponds to the called number. Note that it is corresponds to the called number. Note that it is possible for
possible for multiple parties to be calling a number at the same multiple parties to be calling a number at the same time, and that
time, and that for called numbers such as large call centers, many for called numbers such as large call centers, many PASSporTs could
PASSporTs could legitimately be stored simultaneously, and it might legitimately be stored simultaneously, and it might prove difficult
prove difficult to correlate these with incoming calls. to correlate these with incoming calls.
Assume that an authentication service has created the following Assume that an authentication service has created the following
PASSporT for a call to the telephone number 2.222.222.2222 (note that PASSporT for a call to the telephone number 2.222.222.2222 (note that
these are dummy values): these are dummy values):
eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9j eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9j
ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJkZXN0Ijp7InVyaSI6WyJz ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJkZXN0Ijp7InVyaSI6WyJz
aXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI6IjE0NDMyMDgzNDUiLCJvcmlnI aXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI6IjE0NDMyMDgzNDUiLCJvcmlnI
jp7InRuIjoiMTIxNTU1NTEyMTIifX0.rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1 jp7InRuIjoiMTIxNTU1NTEyMTIifX0.rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1
VOgFWSjHBr8Qjpjlk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w VOgFWSjHBr8Qjpjlk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w
skipping to change at page 18, line 37 skipping to change at page 19, line 47
rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w
MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm
nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV
wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1 wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1
IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j
The web service assigns a new location for this encrypted PASSporT in The web service assigns a new location for this encrypted PASSporT in
the collection, returning a 201 OK with the location of the collection, returning a 201 OK with the location of
/cps/2.222.222.2222/ppts/ppt1. Now the authentication service can /cps/2.222.222.2222/ppts/ppt1. Now the authentication service can
place the call, which may be signaled by various protocols. Once the place the call, which may be signaled by various protocols. Once the
call arrives at the terminating side, a verification service call arrives at the terminating side, a verification service contacts
interrogates its CPS to ask for the set of incoming calls for its its CPS to ask for the set of incoming calls for its telephone number
telephone number (2.222.222.2222). (2.222.222.2222).
GET /cps/2.222.222.2222/ppts GET /cps/2.222.222.2222/ppts
Host: cps.example.com Host: cps.example.com
This returns to the verification service a list of the PASSporTs This returns to the verification service a list of the PASSporTs
currently in the collection, which currently consists of only currently in the collection, which currently consists of only
/cps/2.222.222.2222/ppts/ppt1. The verification service then sends a /cps/2.222.222.2222/ppts/ppt1. The verification service then sends a
new GET for /cps/2.222.222.2222/ppts/ppt1/ which yields: new GET for /cps/2.222.222.2222/ppts/ppt1/ which yields:
HTTP/1.1 200 OK HTTP/1.1 200 OK
skipping to change at page 19, line 32 skipping to change at page 20, line 37
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. Because the storage the calling party number and the called number. Because the storage
of PASSporTs in this architecture is indexed by the called party 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, it makes sense to discover a CPS based on the called party
number as well. There are a number of potential service discovery number as well. There are a number of potential service discovery
mechanisms that could be used for this purpose. The means of service mechanisms that could be used for this purpose. The means of service
discovery may vary by use case. discovery may vary by use case.
Although the discussion above is written in terms of a single CPS, Although the discussion above is written largely in terms of a single
having a significant fraction of all telephone calls result in CPS, 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. Likely models include ones where a
carrier operates one or more CPS instances on behalf of its
customers, enterprises run a CPS instance on behalf of their PBX
users, or where third-party service providers offer a CPS as a cloud
service.
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 (see If a credential lookup service is already available (see
Section 11), the CPS location can also be recorded in the callee's Section 11), the CPS location can also be recorded in the callee's
credentials; an extension to [RFC8226] could for example provide a credentials; an extension to [RFC8226] could for example provide a
link to the location of the CPS where PASSporTs should be stored link to the location of the CPS where PASSporTs should be stored
for a destination. 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.ietf-modern-teri] protocol, could also serve for this
application. application.
Another possibility is to use a single distributed service for Another possibility is to use a single distributed service for
this function. VIPR [I-D.rosenberg-dispatch-vipr-overview] this function. VIPR [I-D.rosenberg-dispatch-vipr-overview]
proposed a RELOAD [RFC6940] usage for telephone numbers to help proposed a RELOAD [RFC6940] usage for telephone numbers to help
direct calls to enterprises on the Internet. It would be possible direct calls to enterprises on the Internet. It would be possible
to describe a similar RELOAD usage to identify the CPS where calls to describe a similar RELOAD usage to identify the CPS where calls
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.
This document does not prescribe any single way to do service This document does not prescribe any single way to do service
discovery for a CPS; it is envisioned that initial deployments will discovery for a CPS; it is envisioned that initial deployments will
provision at the AS and VS. provision the location of the CPS at the AS and VS.
11. Credential Lookup 11. Credential Lookup
In order to encrypt a PASSporT (see Section 6.1), 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. Some initial
does not specify any particular scheme, but a list of requirements STIR deployments have fielded certificate repositories so that
would be something like: 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 credentials for
the called party - provided they can be discovered by calling
parties. This document does not specify any particular discovery
scheme, but a list of requirements and considerations 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).
skipping to change at page 21, line 18 skipping to change at page 22, line 34
there is more modest since an attacker would need to both have the there is more modest since an attacker would need to both have the
callee's credentials and regularly poll the database for every callee's credentials and regularly poll the database for 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.
12. Acknowledgments 12. 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 Jonathan
for helpful suggestions. Rosenberg and Robert Sparks for helpful suggestions.
13. IANA Considerations 13. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
14. Security Considerations 14. Security Considerations
This entire document is about security, but the detailed security This entire document is about security, but the detailed security
properties depend on having a single concrete scheme to analyze. properties depend on having a single concrete scheme to analyze.
15. Informative References 15. Informative References
[I-D.ietf-modern-teri]
Peterson, J., "An Architecture and Information Model for
Telephone-Related Information (TeRI)", draft-ietf-modern-
teri-00 (work in progress), July 2018.
[I-D.ietf-stir-passport-divert] [I-D.ietf-stir-passport-divert]
Peterson, J., "PASSporT Extension for Diverted Calls", Peterson, J., "PASSporT Extension for Diverted Calls",
draft-ietf-stir-passport-divert-02 (work in progress), draft-ietf-stir-passport-divert-05 (work in progress),
March 2018. February 2019.
[I-D.peterson-modern-teri]
Peterson, J., "An Architecture and Information Model for
Telephone-Related Information (TeRI)", draft-peterson-
modern-teri-04 (work in progress), March 2018.
[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,
skipping to change at page 23, line 4 skipping to change at page 24, line 20
Credentials: Certificates", RFC 8226, Credentials: Certificates", RFC 8226,
DOI 10.17487/RFC8226, February 2018, DOI 10.17487/RFC8226, February 2018,
<https://www.rfc-editor.org/info/rfc8226>. <https://www.rfc-editor.org/info/rfc8226>.
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@team.neustar
 End of changes. 55 change blocks. 
213 lines changed or deleted 285 lines changed or added

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