rfc8816.form.txt   rfc8816.txt 
Internet Engineering Task Force (IETF) E.K. Rescorla Internet Engineering Task Force (IETF) E. Rescorla
Request for Comments: 0000 Mozilla Request for Comments: 8816 Mozilla
Category: Informational J. Peterson Category: Informational J. Peterson
ISSN: 2070-1721 Neustar ISSN: 2070-1721 Neustar
3 August 2020 August 2020
STIR Out-of-Band Architecture and Use Cases Secure Telephone Identity Revisited (STIR) Out-of-Band Architecture and
Use Cases
Abstract Abstract
The PASSporT format defines a token that can be carried by signaling The Personal Assertion Token (PASSporT) format defines a token that
protocols, including SIP, to cryptographically attest the identify of can be carried by signaling protocols, including SIP, to
callers. Not all telephone calls use Internet signaling protocols, cryptographically attest the identity of callers. Not all telephone
however, and some calls use them for only part of their signaling calls use Internet signaling protocols, however, and some calls use
path, or cannot reliably deliver SIP header fields end-to-end. This them for only part of their signaling path, or cannot reliably
document describes use cases that require the delivery of PASSporT deliver SIP header fields end-to-end. This document describes use
objects outside of the signaling path, and defines architectures and cases that require the delivery of PASSporT objects outside of the
semantics to provide this functionality. signaling path, and defines architectures and semantics to provide
this functionality.
Status of This Memo Status of This Memo
This document is not an Internet Standards Track specification; it is This document is not an Internet Standards Track specification; it is
published for informational purposes. published for informational purposes.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841. Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata, Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc0000. https://www.rfc-editor.org/info/rfc8816.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
skipping to change at line 60 skipping to change at line 62
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction 1. Introduction
2. Terminology 2. Terminology
3. Operating Environments 3. Operating Environments
4. Dataflows 4. Dataflows
5. Use Cases 5. Use Cases
5.1. Case 1: VoIP to PSTN Call 5.1. Case 1: VoIP to PSTN Call
5.2. Case 2: Two Smart PSTN endpoints 5.2. Case 2: Two Smart PSTN Endpoints
5.3. Case 3: PSTN to VoIP Call 5.3. Case 3: PSTN to VoIP Call
5.4. Case 4: Gateway Out-of-band 5.4. Case 4: Gateway Out-of-Band
5.5. Case 5: Enterprise Call Center 5.5. Case 5: Enterprise Call Center
6. Storing and Retrieving PASSporTs 6. Storing and Retrieving PASSporTs
6.1. Storage 6.1. Storage
6.2. Retrieval 6.2. Retrieval
7. Solution Architecture 7. Solution Architecture
7.1. Credentials and Phone Numbers 7.1. Credentials and Phone Numbers
7.2. Call Flow 7.2. Call Flow
7.3. Security Analysis 7.3. Security Analysis
7.4. Substitution Attacks 7.4. Substitution Attacks
7.5. Rate Control for CPS Storage 7.5. Rate Control for CPS Storage
8. Authentication and Verification Service Behavior for 8. Authentication and Verification Service Behavior for
Out-of-Band Out-of-Band
8.1. Authentication Service (AS) 8.1. Authentication Service (AS)
8.2. Verification Service (VS) 8.2. Verification Service (VS)
8.3. Gateway Placement Services 8.3. Gateway Placement Services
9. Example HTTPS Interface to the CPS 9. Example HTTPS Interface to the CPS
10. CPS Discovery 10. CPS Discovery
11. Encryption Key Lookup 11. Encryption Key Lookup
12. Acknowledgments 12. IANA Considerations
13. IANA Considerations 13. Privacy Considerations
14. Privacy Considerations 14. Security Considerations
15. Security Considerations 15. Informative References
16. Informative References Acknowledgments
Authors' Addresses Authors' Addresses
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 a SIP Identity header impersonation. For example, [RFC8224] defines a SIP Identity header
field capable of carrying PASSporT [RFC8225] objects in SIP as a field capable of carrying PASSporT objects [RFC8225] in SIP as a
means to cryptographically attest that the originator of a telephone means to cryptographically attest that the originator of a telephone
call is authorized to use the calling party number (or, for native call is authorized to use the calling party number (or, for native
SIP cases, SIP URI) associated with the originator of the call. SIP cases, SIP URI) associated with the originator of the 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. Calls from do use SIP do not always carry SIP signaling end-to-end. Calls from
telephone numbers still routinely traverse the Public Switched telephone numbers still routinely traverse the Public Switched
Telephone Network (PSTN) at some point. Broadly, calls fall into one Telephone Network (PSTN) at some point. Broadly, calls fall into one
of three categories: of three 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, etc.) but the
call transits the PSTN at some point. call transits the PSTN at some point.
3. Non-PSTN calls which do not transit the PSTN at all (such as 3. Non-PSTN calls that do not transit the PSTN at all (such as
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 --
indeed any inband signaling data--intact. Even if fields for or indeed any in-band signaling data -- intact. Even if fields for
tunneling arbitrary 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.
While the core network of the PSTN remains fixed, the endpoints of While the core network of the PSTN remains fixed, the endpoints of
the telephone network are becoming increasingly programmable and 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 Private Branch Exchanges (PBXs), and terminal adapters. All three
computers, and typically all three have Internet access as well as are general purpose computers, and typically all three have Internet
access to the PSTN; they may be used for residential, mobile, or access as well as access to the PSTN; they may be used for
enterprise telephone services. Additionally, various kinds of residential, mobile, or enterprise telephone services. Additionally,
gateways increasingly front for deployments of legacy PBX and PSTN various kinds of gateways increasingly front for deployments of
switches. All of this provides a potential avenue for building an legacy PBX and PSTN switches. All of this provides a potential
authentication system that implements stronger identity while leaving avenue for building an authentication system that implements stronger
PSTN systems intact. 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.
The techniques described in this document therefore build on the The techniques described in this document therefore build on the
PASSporT [RFC8225] mechanism and the work of [RFC8224] to describe a PASSporT [RFC8225] mechanism and the work of [RFC8224] to describe a
way that a PASSporT object created in the originating network of a way that a PASSporT object created in the originating network of a
call can reach the terminating network even when it cannot be carried call can reach the terminating network even when it cannot be carried
end-to-end in-band in the call signaling. This relies on a new end-to-end in-band in the call signaling. This relies on a new
service defined in this document called a Call Placement Service service defined in this document called a Call Placement Service
(CPS) that permits the PASSporT object to be stored during call (CPS) that permits the PASSporT object to be stored during call
processing and retrieved for verification purposes. processing and retrieved for verification purposes.
Potential implementors should note that this document merely defines Potential implementors should note that this document merely defines
the operating environments in which this out-of-band STIR mechanism the operating environments in which this out-of-band STIR mechanism
is intended to operate. It provides use cases, gives a broad is intended to operate. It provides use cases, gives a broad
description of the components and a potential solution architecture. description of the components, and a potential solution architecture.
Various environments may have their own security requirements: a Various environments may have their own security requirements: a
public deployment of out-of-band STIR faces far greater challenges public deployment of out-of-band STIR faces far greater challenges
than a constrained intranetwork deployment. To flesh out the storage than a constrained intra-network deployment. To flesh out the
and retrieval of PASSporTs in the CPS within this context, this storage and retrieval of PASSporTs in the CPS within this context,
document includes a strawman protocol suitable for that purpose. this document includes a strawman protocol suitable for that purpose.
Deploying this framework in any given environment would require Deploying this framework in any given environment would require
additional specification outside the scope of the current document. additional specification outside the scope of this document.
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 "OPTIONAL" in this document are to be interpreted as described in BCP
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Operating Environments 3. Operating Environments
This section describes the environments in which the proposed out-of- This section describes the environments in which the proposed out-of-
band STIR mechanism is intended to operate. In the simplest setting, band STIR mechanism is intended to operate. In the simplest setting,
Alice is calling Bob, and her call is routed through some set of Alice calls Bob, and her call is routed through some set of gateways
gateways and/or the PSTN which do not support end-to-end delivery of and/or the PSTN that do not support end-to-end delivery of STIR.
STIR. Both Alice and Bob have smart devices which can access the Both Alice and Bob have smart devices that can access the Internet
Internet (perhaps enterprise devices, or even end user ones), but (perhaps enterprise devices, or even end-user ones), but they do not
they do not have a clear telephone signaling connection between them: have a clear telephone signaling connection between them: Alice
Alice cannot inject any data into signaling which Bob can read, with cannot inject any data into signaling that Bob can read, with the
the exception of the asserted destination and origination E.164 exception of the asserted destination and origination E.164 numbers.
numbers. The calling party number might originate from her own The calling party number might originate from her own device or from
device or from the network. These numbers are effectively the only the network. These numbers are effectively the only data that can be
data that can be used for coordination between the endpoints. used for coordination between the endpoints.
+---------+ +---------+
/ \ / \
+--- +---+ +--- +---+
+----------+ / \ +----------+ +----------+ / \ +----------+
| | | Gateways | | | | | | Gateways | | |
| Alice |<----->| and/or |<----->| Bob | | Alice |<----->| and/or |<----->| Bob |
| (caller) | | PSTN | | (callee) | | (caller) | | PSTN | | (callee) |
+----------+ \ / +----------+ +----------+ \ / +----------+
+--- +---+ +--- +---+
skipping to change at line 226 skipping to change at line 228
+----------+ +--+ / \ +--+ +----------+ +----------+ +--+ / \ +--+ +----------+
| | | | | Gateways | | | | | | | | | | Gateways | | | | |
| Alice |<-|GW|->| and/or |<-|GW|->| Bob | | Alice |<-|GW|->| and/or |<-|GW|->| Bob |
| (caller) | | | | PSTN | | | | (callee) | | (caller) | | | | PSTN | | | | (callee) |
+----------+ +--+ \ / +--+ +----------+ +----------+ +--+ \ / +--+ +----------+
+--- +---+ +--- +---+
\ / \ /
+---------+ +---------+
In such a case, Alice might have an analog (e.g., PSTN) connection to In such a case, Alice might have an analog (e.g., PSTN) connection to
her gateway/ switch which is responsible for her identity. her gateway or switch that is responsible for her identity.
Similarly, the gateway would verify Alice's identity, generate the Similarly, the gateway would verify Alice's identity, generate the
right calling party number information and provide that number to Bob right calling party number information, and provide that number to
using ordinary Plain Ol' Telephone Service (POTS) mechanisms. Bob using ordinary Plain Old Telephone Service (POTS) mechanisms.
4. Dataflows 4. Dataflows
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 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 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 operate a CPS or mandate any means to discover a CPS. A CPS could be
be run internally within a network, or made publicly available. One run internally within a network or made publicly available. One or
or more CPSes could be run by a carrier, as repositories for more CPSes could be run by a carrier, as repositories for PASSporTs
PASSporTs for calls sent to its customers, or a CPS could be built-in for calls sent to its customers, or a CPS could be built into an
to an enterprise PBX, or even a smartphone. To the degree possible, enterprise PBX or even a smartphone. To the degree possible, it is
it is specified here generically, as an idea that may have specified here generically as an idea that may have applicability to
applicability to a variety of STIR deployments. 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:
1. The callee registers with the CPS. When the caller wishes to 1. The callee registers with the CPS. When the caller wishes to
place a call to the callee, it sends the PASSporT to the CPS, place a call to the callee, it sends the PASSporT to the CPS,
which immediately forwards it to the callee, or, which immediately forwards it to the callee.
2. The caller stores the PASSporT with the CPS at the time of call 2. The caller stores the PASSporT with the CPS at the time of call
placement. When the callee receives the call, it contacts the placement. When the callee receives the call, it contacts the
CPS and retrieves the PASSporT. CPS and retrieves the PASSporT.
While the first architecture is roughly isomorphic to current VoIP While the first architecture is roughly isomorphic to current VoIP
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. In specialized environments, for the CPS to retrieve the PASSporT. In specialized environments, for
example a call center that receives a large volume of incoming calls example, a call center that receives a large volume of incoming calls
that originated in the PSTN, the notification channel approach might that originated in the PSTN, the notification channel approach might
be viable. 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 header fields in a single SIP INVITE, so there may be multiple
this out-of-band mechanism associated with a single call. For PASSporTs in this out-of-band mechanism associated with a single
example, a SIP user agent might create a PASSporT for a call with an call. For example, a SIP user agent might create a PASSporT for a
end user credential, and as the call exits the originating call with an end-user credential, and as the call exits the
administrative domain the network authentication service might create originating administrative domain, the network authentication service
its own PASSporT for the same call. As such, these use cases may might create its own PASSporT for the same call. As such, these use
overlap in the processing of a single call. cases may overlap in the processing of a single call.
5.1. Case 1: VoIP to PSTN Call 5.1. Case 1: VoIP to PSTN Call
A call originates in a SIP environment in a STIR-aware administrative A call originates in a SIP environment in a STIR-aware administrative
domain. The local authentication service for that administrative domain. The local authentication service for that administrative
domain creates a PASSporT which is carried in band in the call per domain creates a PASSporT that is carried in band in the call per
[RFC8224]. The call is routed out of the originating administrative [RFC8224]. The call is routed out of the originating administrative
domain and reaches a gateway to the PSTN. Eventually, the call will domain and reaches a gateway to the PSTN. Eventually, the call will
terminate on a mobile smartphone that supports this out-of-band terminate on a mobile smartphone that supports this out-of-band
mechanism. mechanism.
In this use case, the originating authentication service can store In this use case, the originating authentication service can store
the PASSporT with the appropriate CPS (per the practices of the PASSporT with the appropriate CPS (per the practices of
Section 10) for the target telephone number as a fallback in case SIP Section 10) for the target telephone number as a fallback in case SIP
signaling will not reach end-to-end. When the destination mobile signaling will not reach end-to-end. When the destination mobile
smartphone receives the call over the PSTN, it consults the CPS and smartphone receives the call over the PSTN, it consults the CPS and
discovers a PASSporT from the originating telephone number waiting discovers a PASSporT from the originating telephone number waiting
for it. It uses this PASSporT to verify the calling party number. for it. It uses this PASSporT to verify the calling party number.
5.2. Case 2: Two Smart PSTN endpoints 5.2. Case 2: Two Smart PSTN Endpoints
A call originates with an enterprise PBX that has both Internet A call originates with an enterprise PBX that has both Internet
access and a built-in gateway to the PSTN, which communicates through access and a built-in gateway to the PSTN, which communicates through
traditional telephone signaling protocols. The PBX immediately traditional telephone signaling protocols. The PBX immediately
routes the call to the PSTN, but before it does, it provisions a routes the call to the PSTN, but before it does, it provisions a
PASSporT on the CPS associated with the target telephone number. PASSporT on the CPS associated with the target telephone number.
After normal PSTN routing, the call lands on a smart mobile handset After normal PSTN routing, the call lands on a smart mobile handset
that supports the STIR out-of-band mechanism. It queries the that supports the STIR out-of-band mechanism. It queries the
appropriate CPS over the Internet to determine if a call has been appropriate CPS over the Internet to determine if a call has been
skipping to change at line 346 skipping to change at line 348
In this case, there are two subcases for how the PASSporT might be In this case, there are two subcases for how the PASSporT might be
retrieved. In subcase 1, the Internet gateway that receives the call retrieved. In subcase 1, the Internet gateway that receives the call
from the PSTN could query the appropriate CPS to determine if the from the PSTN could query the appropriate CPS to determine if the
original caller created and provisioned a PASSporT for this call. If original caller created and provisioned a PASSporT for this call. If
so, it can retrieve the PASSporT and, when it creates a SIP INVITE so, it can retrieve the PASSporT and, when it creates a SIP INVITE
for this call, add a corresponding Identity header field per for this call, add a corresponding Identity header field per
[RFC8224]. When the SIP INVITE reaches the destination [RFC8224]. When the SIP INVITE reaches the destination
administrative domain, it will be able to verify the PASSporT administrative domain, it will be able to verify the PASSporT
normally. Note that to avoid discrepancies with the Date header normally. Note that to avoid discrepancies with the Date header
field value, only full-form PASSporT should be used for this purpose. field value, only a full-form PASSporT should be used for this
In subcase 2, the gateway does not retrieve the PASSporT itself, but purpose. In subcase 2, the gateway does not retrieve the PASSporT
instead the verification service at the destination administrative itself, but instead the verification service at the destination
domain does so. Subcase 1 would perhaps be valuable for deployments administrative domain does so. Subcase 1 would perhaps be valuable
where the destination administrative domain supports in-band STIR but for deployments where the destination administrative domain supports
not out-of-band STIR. in-band STIR but not out-of-band STIR.
5.4. Case 4: Gateway Out-of-band 5.4. Case 4: Gateway Out-of-Band
A call originates in the SIP world in a STIR-aware administrative A call originates in the SIP world in a STIR-aware administrative
domain. The local authentication service for that administrative domain. The local authentication service for that administrative
domain creates a PASSporT which is carried in band in the call per domain creates a PASSporT that is carried in band in the call per
[RFC8224]. The call is routed out of the originating administrative [RFC8224]. The call is routed out of the originating administrative
domain and eventually reaches a gateway to the PSTN. domain and eventually reaches a gateway to the PSTN.
In this case, the originating authentication service does not support In this case, the originating authentication service does not support
the out-of-band mechanism, so instead the gateway to the PSTN the out-of-band mechanism, so instead the gateway to the PSTN
extracts the PASSporT from the SIP request and provisions it to the extracts the PASSporT from the SIP request and provisions it to the
CPS. (When the call reaches the gateway to the PSTN, the gateway CPS. (When the call reaches the gateway to the PSTN, the gateway
might first check the CPS to see if a PASSporT object had already might first check the CPS to see if a PASSporT object had already
been provisioned for this call, and only provision a PASSporT if none been provisioned for this call, and only provision a PASSporT if none
is present). is present).
Ultimately, the call may terminate on the PSTN, or be routed back to Ultimately, the call may terminate on the PSTN or be routed back to a
a SIP environment. In the former case, perhaps the destination SIP environment. In the former case, perhaps the destination
endpoint queries the CPS to retrieve the PASSporT provisioned by the endpoint queries the CPS to retrieve the PASSporT provisioned by the
first gateway. Or if the call ultimately returns to a SIP first gateway. If the call ultimately returns to a SIP environment,
environment, it might be the gateway from the PSTN back to the it might be the gateway from the PSTN back to the Internet that
Internet that retrieves the PASSporT from the CPS and attaches it to retrieves the PASSporT from the CPS and attaches it to the new SIP
the new SIP INVITE it creates, or it might be the terminating INVITE it creates, or it might be the terminating administrative
administrative domain's verification service that checks the CPS when domain's verification service that checks the CPS when an INVITE
an INVITE arrives with no Identity header field. Either way the arrives with no Identity header field. Either way, the PASSporT can
PASSporT can survive the gap in SIP coverage caused by the PSTN leg survive the gap in SIP coverage caused by the PSTN leg of the call.
of the call.
5.5. Case 5: Enterprise Call Center 5.5. Case 5: Enterprise Call Center
A call originates from a mobile user, and a STIR authentication A call originates from a mobile user, and a STIR authentication
service operated by their carrier creates a PASSporT for the call. service operated by their carrier creates a PASSporT for the call.
As the carrier forwards the call via SIP, it attaches the PASSporT to As the carrier forwards the call via SIP, it attaches the PASSporT to
the SIP call with an Identity header field. As a fallback in case the SIP call with an Identity header field. As a fallback in case
the call will not go end-to-end over SIP, the carrier also stores the the call will not go end-to-end over SIP, the carrier also stores the
PASSporT in a CPS. PASSporT in a CPS.
skipping to change at line 405 skipping to change at line 406
computer to manage inbound calls and can receive STIR notifications computer to manage inbound calls and can receive STIR notifications
through it. When the PASSporT arrives at the CPS, it is sent through through it. When the PASSporT arrives at the CPS, it is sent through
a subscription/notification interface to a system that can correlate a subscription/notification interface to a system that can correlate
incoming calls with valid PASSporTs. The call center agent sees that incoming calls with valid PASSporTs. The call center agent sees that
a valid call from the originating number has arrived. a valid call 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 PASSporTs is thus a key design decision in
the architecture. The STIR architecture assumes that service the architecture. The STIR architecture assumes that service
providers and in some cases end user devices will have credentials providers and, in some cases, end-user devices will have credentials
suitable for attesting authority over telephone numbers per suitable for attesting authority over telephone numbers per
[RFC8226]. These credentials provide the most obvious way that a CPS [RFC8226]. These credentials provide the most obvious way that a CPS
can authorize the storage and retrieval of PASSporTs. However, as can authorize the storage and retrieval of PASSporTs. However, as
use cases 3, 4 and 5 in Section 5 show, it may sometimes make sense use cases 3, 4, and 5 in Section 5 show, it may sometimes make sense
for the entity storing or retrieving PASSporTs to be an intermediary for the entity storing or retrieving PASSporTs to be an intermediary
rather than a device associated with either the originating or rather than a device associated with either the originating or
terminating side of a call, and those intermediaries often would not terminating side of a call; those intermediaries often would not have
have access to STIR credentials covering the telephone numbers in access to STIR credentials covering the telephone numbers in
question. Requiring authorization based on a credential to store question. Requiring authorization based on a credential to store
PASSporTs is therefore undesirable, though potentially acceptable if PASSporTs is therefore undesirable, though potentially acceptable if
sufficient steps are taken to mitigate any privacy risk of leaking sufficient steps are taken to mitigate any privacy risk of leaking
data. data.
It is an explicit design goal of this mechanism to minimize the It is an explicit design goal of this mechanism to minimize the
potential privacy exposure of using a CPS. Ideally, the out-of-band potential privacy exposure of using a CPS. Ideally, the out-of-band
mechanism should not result in a worse privacy situation than in-band mechanism should not result in a worse privacy situation than in-band
[RFC8224] STIR: for in-band, we might say that a SIP entity is STIR [RFC8224]: for in-band, we might say that a SIP entity is
authorized to receive a PASSporT if it is an intermediate or final authorized to receive a PASSporT if it is an intermediate or final
target of the routing of a SIP request. As the originator of a call target of the routing of a SIP request. As the originator of a call
cannot necessarily predict the routing path a call will follow, an cannot necessarily predict the routing path a call will follow, an
out-of-band mechanism could conceivably even improve on the privacy out-of-band mechanism could conceivably even improve on the privacy
story. story.
Broadly, the architecture recommended here thus is one focused on Broadly, the architecture recommended here thus is one focused on
permitting any entity to store encrypted PASSporTs at the CPS, permitting any entity to store encrypted PASSporTs at the CPS,
indexed under the called number. PASSporTs will be encrypted with a indexed under the called number. PASSporTs will be encrypted with a
public key associated with the called number, so these PASSporTs may public key associated with the called number, so these PASSporTs may
safely be retrieved by any entity, as only holders of the safely be retrieved by any entity because only holders of the
corresponding private key will be able to decrypt the PASSporT. This corresponding private key will be able to decrypt the PASSporT. This
also prevents the CPS itself from learning the contents of PASSporTs, also prevents the CPS itself from learning the contents of PASSporTs,
and thus metadata about calls in progress, which makes the CPS a less and thus metadata about calls in progress, which makes the CPS a less
attractive target for pervasive monitoring (see [RFC7258]). As a attractive target for pervasive monitoring (see [RFC7258]). As a
first step, transport-level security can provide confidentiality from first step, transport-level security can provide confidentiality from
eavesdroppers for both the storing and retrieval of PASSporTs. To eavesdroppers for both the storing and retrieval of PASSporTs. To
bolster the privacy story, prevent denial-of-service flooding of the bolster the privacy story, to prevent denial-of-service flooding of
CPS, and to complicate traffic analysis, a few additional mechanisms the CPS, and to complicate traffic analysis, a few additional
are also recommended below. mechanisms are also recommended below.
6.1. Storage 6.1. Storage
There are a few dimensions to authorizing the storage of PASSporTs. There are a few dimensions to authorizing the storage of PASSporTs.
Encrypting PASSporTs prior to storage entails that a CPS has no way Encrypting PASSporTs prior to storage entails that a CPS has no way
to tell if a PASSporT is valid; it simply conveys encrypted blocks to tell if a PASSporT is valid; it simply conveys encrypted blocks
that it cannot access itself, and can make no authorization decision that it cannot access itself and can make no authorization decision
based on the PASSporT contents. There is certainly no prospect for based on the PASSporT contents. There is certainly no prospect for
the CPS to verify the PASSporTs itself. the CPS to verify the PASSporTs itself.
Note that this architecture requires clients that store PASSporTs to Note that this architecture requires clients that store PASSporTs to
have access to an encryption key associated with the intended called have access to an encryption key associated with the intended called
party to be used to encrypt the PASSporT. Discovering this key party to be used to encrypt the PASSporT. Discovering this key
requires the existence of a key lookup service (see Section 11); requires the existence of a key lookup service (see Section 11),
depending on how the CPS is architected, however, some kind of key depending on how the CPS is architected; however, some kind of key
store or repository could be implemented adjacent to it, and perhaps store or repository could be implemented adjacent to it and perhaps
even incorporated into its operation. Key discovery is made more even incorporated into its operation. Key discovery is made more
complicated by the fact that there can potentially be multiple complicated by the fact that there can potentially be multiple
entities that have authority over a telephone number: a carrier, a entities that have authority over a telephone number: a carrier, a
reseller, an enterprise, and an end user might all have credentials reseller, an enterprise, and an end user might all have credentials
permitting them to attest that they are allowed to originate calls permitting them to attest that they are allowed to originate calls
from a number, say. PASSporTs for out-of-band use therefore might from a number, say. PASSporTs for out-of-band use therefore might
need to be encrypted with multiple keys in the hopes that one will be need to be encrypted with multiple keys in the hopes that one will be
decipherable by the relying party. decipherable by the relying party.
Again, the most obvious way to authorize storage is to require the Again, the most obvious way to authorize storage is to require the
skipping to change at line 506 skipping to change at line 507
6.2. Retrieval 6.2. Retrieval
For retrieval of PASSporTs, this architecture assumes that clients For retrieval of PASSporTs, this architecture assumes that clients
will contact the CPS through some sort of polling or notification will contact the CPS through some sort of polling or notification
interface to receive all current PASSporTs for calls destined to a interface to receive all current PASSporTs for calls destined to a
particular telephone number, or block of numbers. particular telephone number, or block of numbers.
As PASSporTs stored at the CPS are encrypted with a key belonging to As PASSporTs stored at the CPS are encrypted with a key belonging to
the intended destination, the CPS can safely allow anyone to download the intended destination, the CPS can safely allow anyone to download
PASSporTs for a called number without much fear of compromising PASSporTs for a called number without much fear of compromising
private information about calls in progress - provided that the CPS private information about calls in progress -- provided that the CPS
always returns at least one encrypted blob in response to a request, always returns at least one encrypted blob in response to a request,
even if there was no call in progress. Otherwise, entities could even if there was no call in progress. Otherwise, entities could
poll the CPS constantly, or eavesdrop on traffic, to learn whether or poll the CPS constantly, or eavesdrop on traffic, to learn whether or
not calls were in progress. The CPS MUST generate at least one not calls were in progress. The CPS MUST generate at least one
unique and plausible encrypted response to all retrieval requests, unique and plausible encrypted response to all retrieval requests,
and these dummy encrypted PASSporTs MUST NOT be repeated for later and these dummy encrypted PASSporTs MUST NOT be repeated for later
calls. An encryption scheme needs to be carefully chosen to make calls. An encryption scheme needs to be carefully chosen to make
messages look indistinguishable from random when encrypted, so that messages look indistinguishable from random when encrypted, so that
information about called party is not discoverable from legitimate information about the called party is not discoverable from
encrypted PASSporTs. legitimate encrypted PASSporTs.
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 to decrypt all PASSporTs retrieved from the CPS, and may find need to decrypt all PASSporTs retrieved from the CPS, and may find
only one that is valid. only one that is valid.
In order to prevent the CPS from learning the numbers that a callee In order to prevent the CPS from learning the numbers that a callee
controls, callees might also request PASSporTs for numbers that they controls, callees might also request PASSporTs for numbers that they
do not own, that they have no hope of decrypting. Implementations do not own, that they have no hope of decrypting. Implementations
could even allow a callee to request PASSporTs for a range or prefix could even allow a callee to request PASSporTs for a range or prefix
of numbers: a trade-off where that callee is willing to sift through of numbers: a trade-off where that callee is willing to sift through
bulk quantities of undecryptable PASSporTs for the sake of hiding bulk quantities of undecryptable PASSporTs for the sake of hiding
from the CPS what numbers it controls. from the CPS which numbers it controls.
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 [PASSPORT-DIVERT]. The originating diversion extension [PASSPORT-DIVERT]. The originating
authentication service would encrypt the initial PASSporT with the authentication service encrypts the initial PASSporT with the public
public encryption key of the intended destination, but once a call is encryption key of the intended destination, but once a call is
forwarded, it may go to a destination that does not possess the forwarded, it may go to a destination that does not possess the
corresponding private key and thus could not decrypt the original corresponding private key and thus could not decrypt the original
PASSporT. This requires the retargeting entity to generate encrypted PASSporT. This requires the retargeting entity to generate encrypted
PASSporTs that show a secure chain of diversion: a retargeting storer PASSporTs that show a secure chain of diversion: a retargeting storer
SHOULD use the "div-o" PASSporT type, with its "opt" extension, as SHOULD use the "div-o" PASSporT type, with its "opt" extension, as
specified in [PASSPORT-DIVERT] in order to nest the original PASSporT specified in [PASSPORT-DIVERT], in order to nest the original
within the encrypted diversion 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.
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 that 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. [RFC8226] describes a they have the appropriate authority. [RFC8226] describes a
credential system suitable for this purpose; the question of how an credential system suitable for this purpose; the question of how an
entity is determined to have control of a given number is out of entity is determined to have control of a given number is out of
scope for the current document. scope for this document.
7.2. Call Flow 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.555.1111 and Bob has the number +2.222.555.2222. +1.111.555.1111 and Bob has the number +2.222.555.2222.
Alice Call Placement Service Bob Alice Call Placement Service Bob
-------------------------------------------------------------------- --------------------------------------------------------------------
Store Encrhypted PASSporT for 2.222.555.2222 -> Store Encrypted PASSporT for 2.222.555.2222 ->
Call from 1.111.555.1111 ------------------------------------------> Call from 1.111.555.1111 ------------------------------------------>
<-------------- Request PASSporT(s) <-------------- Request PASSporT(s)
for 2.222.555.2222 for 2.222.555.2222
Obtain Encrypted PASSporT --------> Obtain Encrypted PASSporT -------->
(2.222.555.2222, 1.111.555.1111) (2.222.555.2222, 1.111.555.1111)
[Ring phone with verified callerid [Ring phone with verified callerid
= 1.111.555.1111] = 1.111.555.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 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.
When Alice places the call, Bob's phone would usually ring and When Alice places the call, Bob's phone would usually ring and
display Alice's number (+1.111.555.1111), which is informed by the display Alice's number (+1.111.555.1111), which is informed by the
existing PSTN mechanisms for relaying a calling party number (e.g., existing PSTN mechanisms for relaying a calling party number (e.g.,
the CIN field of the IAM). Instead, Bob's phone transparently the CIN field of the Initial Address Message (IAM)). Instead, Bob's
contacts the CPS and requests any current PASSporTs for calls to his phone transparently contacts the CPS and requests any current
number. The CPS responds with any such PASSporTs (or dummy PASSporTs PASSporTs for calls to his number. The CPS responds with any such
if no relevant ones are currently stored). If such a PASSporT PASSporTs (or dummy PASSporTs if no relevant ones are currently
exists, and the verification service in Bob's phone decrypts it using stored). If such a PASSporT exists, and the verification service in
his private key, validates it, then Bob's phone can present the Bob's phone decrypts it using his private key, validates it, then
calling party number information as valid. Otherwise, the call is Bob's phone can present the calling party number information as
unverifiable. Note that this does not necessarily mean that the call valid. 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:
1. The attacker wishes to impersonate a target when no call from 1. The attacker wishes to impersonate a target when no call from
that target is in progress. that target is in progress.
2. The attacker wishes to substitute himself for an existing call 2. The attacker wishes to substitute himself for an existing call
setup. setup.
If an attacker can inject fake PASSporTs into the CPS or in the If an attacker can inject fake PASSporTs into the CPS or in the
communication from the CPS to the callee, he can mount either attack. 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. Any attacker who is aware should not arise in ordinary operations. Any attacker who is aware
of calls in progress can attempt to mount a race to subtitute of calls in progress can attempt to mount a race to substitute
themselves as described in Section 7.4. For privacy and robustness themselves as described in Section 7.4. For privacy and robustness
reasons, using TLS [RFC8446] on the originating side when storing the reasons, using TLS [RFC8446] on the originating side when storing the
PASSporT at the CPS is RECOMMENDED. PASSporT 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 STIR [RFC8224].
A secondary attack we must also prevent is denial-of-service against A secondary attack we must also prevent is denial-of-service against
the CPS, which requires some form of rate control solution that will the CPS, which requires some form of rate control solution that will
not degrade the privacy properties of the architecture. not degrade the privacy properties of the architecture.
7.4. Substitution Attacks 7.4. Substitution Attacks
All the receipt of the PASSporT from the CPS proves to the called All that the receipt of the PASSporT from the CPS proves to the
party is that Alice is trying to call Bob (or at least was as of very called party is that Alice is trying to call Bob (or at least was as
recently) - it does not prove that any particular incoming call is of very recently) -- it does not prove that any particular incoming
from Alice. Consider the scenario in which we have a service which call is from Alice. Consider the scenario in which we have a service
provides an automatic callback to a user-provided number. In that that provides an automatic callback to a user-provided number. In
case, the attacker can try to arrange for a false caller-id value, as that case, the attacker can try to arrange for a false caller-id
shown below: value, as shown below:
Attacker Callback Service CPS Bob Attacker Callback Service CPS Bob
-------------------------------------------------------------------- --------------------------------------------------------------------
Place call to Bob ----------> Place call to Bob ---------->
(from 111.555.1111) (from 111.555.1111)
Store PASSporT for Store PASSporT for
CS:Bob -------------> CS:Bob ------------->
Call from Attacker (forged CS caller-id info) --------------------> Call from Attacker (forged CS caller-id info) -------------------->
skipping to change at line 682 skipping to change at line 683
In order to mount this attack, the attacker contacts the Callback In order to mount this attack, the attacker contacts the Callback
Service (CS) and provides it with Bob's number. This causes the CS Service (CS) and provides it with Bob's number. This causes the CS
to initiate a call to Bob. As before, the CS contacts the CPS to to initiate a call to Bob. As before, the CS contacts the CPS to
insert an appropriate PASSporT and then initiates a call to Bob. 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. mail/call waiting.
In order to prevent a passive attacker from using traffic analysis or In order to prevent a passive attacker from using traffic analysis or
similar means to learn precisely when a call is placed, it is similar means to learn precisely when a call is placed, it is
essential that the connection between the caller and the CPS be essential that the connection between the caller and the CPS be
encrypted as recommended above. Authentication services could store encrypted as recommended above. Authentication services could store
dummy PASSporTs at the CPS at random intervals in order to make it dummy PASSporTs at the CPS at random intervals in order to make it
more difficult for an eavesdropper to use traffic analysis to more difficult for an eavesdropper to use traffic analysis to
determine that a call was about to be placed. determine that a call was about to be placed.
skipping to change at line 709 skipping to change at line 710
CPS, so shortening that window will reduce the opportunity for the CPS, so shortening that window will reduce the opportunity for the
attack. Finally, smart endpoints could implement some sort of state attack. Finally, smart endpoints could implement some sort of state
coordination to ensure that both sides believe the call is in coordination to ensure that both sides believe the call is in
progress, though methods of supporting that are outside the scope of progress, though methods of supporting that are outside the scope of
this document. this document.
7.5. Rate Control for CPS Storage 7.5. Rate Control for CPS Storage
In order to prevent the flooding of a CPS with bogus PASSporTs, we In order to prevent the flooding of a CPS with bogus PASSporTs, we
propose the use of "blind signatures" (see [RFC5636]). A sender will propose the use of "blind signatures" (see [RFC5636]). A sender will
initially authenticate to the CPS using its STIR credentials, and initially authenticate to the CPS using its STIR credentials and
acquire a signed token from the CPS that will be presented later when acquire a signed token from the CPS that will be presented later when
storing a PASSporT. The flow looks as follows: storing a PASSporT. The flow looks as follows:
Sender CPS Sender CPS
Authenticate to CPS ---------------------> Authenticate to CPS --------------------->
Blinded(K_temp) -------------------------> Blinded(K_temp) ------------------------->
<------------- Sign(K_cps, Blinded(K_temp)) <------------- Sign(K_cps, Blinded(K_temp))
[Disconnect] [Disconnect]
Sign(K_cps, K_temp) Sign(K_cps, K_temp)
Sign(K_temp, E(K_receiver, PASSporT)) ---> Sign(K_temp, E(K_receiver, PASSporT)) --->
At an initial time when no call is yet in progress, a potential At an initial time when no call is yet in progress, a potential
client connects to the CPS, authenticates, and sends a blinded client connects to the CPS, authenticates, and sends a blinded
version of a freshly generated public key. The CPS returns a signed 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 version of that blinded key. The sender can then unblind the key and
gets a signature on K_temp from the CPS. get a signature on K_temp from the CPS.
Then later, when a client wants to store a PASSporT, it connects to Then later, when a client wants to store a PASSporT, it connects to
the CPS anonymously (preferably over a network connection that cannot the CPS anonymously (preferably over a network connection that cannot
be correlated with the token acquisition) and sends both the signed be correlated with the token acquisition) and sends both the signed
K_temp and its own signature over the encrypted PASSporT. The CPS K_temp and its own signature over the encrypted PASSporT. The CPS
verifies both signatures and if they verify, stores the encrypted verifies both signatures and, if they verify, stores the encrypted
passport (discarding the signatures). passport (discarding the signatures).
This design lets the CPS rate limit how many PASSporTs a given sender 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 can store just by counting how many times K_temp appears; perhaps CPS
policy might reject storage attempts and require acquisition of a new policy might reject storage attempts and require acquisition of a new
K_temp after storing more than a certain number of PASSporTs indexed K_temp after storing more than a certain number of PASSporTs indexed
under the same destination number in a short interval. This does not under the same destination number in a short interval. This does
of course allow the CPS to tell when bogus data is being provisioned not, of course, allow the CPS to tell when bogus data is being
by an attacker, simply the rate at which data is being provisioned. provisioned by an attacker, simply the rate at which data is being
Potentially, feedback mechanisms could be developed that would allow provisioned. Potentially, feedback mechanisms could be developed
the called parties to tell the CPS when they are receiving unusual or that would allow the called parties to tell the CPS when they are
bogus PASSporTs. receiving unusual or bogus PASSporTs.
This architecture also assumes that the CPS will age out PASSporTs. This architecture also assumes that the CPS will age out PASSporTs.
A CPS SHOULD NOT keep any stored PASSporT for no longer than a value A CPS SHOULD NOT keep any stored PASSporT for no longer than a value
that might be selected for the verification service policy for that might be selected for the verification service policy for
freshness of the "iat" value as described in [RFC8224] (i.e. sixty freshness of the "iat" value as described in [RFC8224] (i.e., sixty
seconds). Any reduction in this window makes substitution attacks seconds). Any reduction in this window makes substitution attacks
(see Section 7.4) harder to mount, but making the window too small (see Section 7.4) harder to mount, but making the window too small
might conceivably age PASSporTs out while a heavily redirected call might conceivably age PASSporTs out while a heavily redirected call
is still alerting. is still alerting.
An alternative potential approach to blind signatures would be the An alternative potential approach to blind signatures would be the
use of oblivious pseudorandom functions (VOPRFs, per [PRIVACY-PASS]), use of verifiable oblivious pseudorandom functions (VOPRFs, per
which move prove faster. [PRIVACY-PASS]), which move prove faster.
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 line 788 skipping to change at line 789
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 some other identifier. For a domain or a telephone number or some 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 into the calling device, for example, this is the same check
performed in Step 1: does the calling device hold a private key, one performed in Step 1: does the calling device hold a private key, 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 encryption Step 3: The authentication service MUST acquire the public encryption
key of the destination, which will be used to encrypt the PASSporT key of the destination, which will be used to encrypt the PASSporT
(see Section 11). It MUST also discover (see Section 10) the CPS (see Section 11). It MUST also discover (see Section 10) the CPS
associated with the destination. The authentication service may associated with the destination. The authentication service may
already have the encryption key and destination CPS cached, or may already have the encryption key and destination CPS cached, or may
need to query a service to acquire the key. Note that per need to query a service to acquire the key. Note that per
Section 7.5 the authentication service may also need to acquire a Section 7.5, the authentication service may also need to acquire a
token for PASSporT storage from the CPS upon CPS discovery. It is token for PASSporT storage from the CPS upon CPS discovery. It is
anticipated that the discovery mechanism (see Section 10) used to anticipated that the discovery mechanism (see Section 10) used to
find the appropriate CPS will also find the proper key server for the find the appropriate CPS will also find the proper key server for the
public key of the destination. In some cases, a destination may have public key of the destination. In some cases, a destination may have
multiple public encryption keys associated with it. In that case, multiple public encryption keys associated with it. In that case,
the authentication service MUST collect all of those keys. the authentication service MUST collect all of 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 be 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 a cleartext version rather than an encrypted version sent to carry a cleartext version rather than an encrypted version sent to
the CPS. In that case, out-of-band would serve as a fallback the 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. mechanism if the request was not conveyed over SIP end-to-end. Also,
Also, note that the authentication service MAY use a compact form of note that the authentication service MAY use a compact form of the
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 (VS) 8.2. Verification Service (VS)
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; or alternatively it may current PASSporTs for its destination number; or alternatively it may
receive PASSporTs through a push interface from the CPS in some receive PASSporTs through a push interface from the CPS in some
deployments. The verification service MUST then decrypt all deployments. The verification service MUST then decrypt all
skipping to change at line 873 skipping to change at line 874
signature over each PASSporT, as 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. In keeping with PASSporTs corresponding to the call it has received. In keeping with
baseline STIR, this document does not dictate any particular baseline STIR, this document does not dictate any particular
treatment of calls that have valid PASSporTs associated with them; treatment of calls that have valid PASSporTs associated with them;
the handling of the call after the verification process depends on the handling of the call after the verification process depends on
how the verification service is implemented and on local policy. how the verification service is implemented and on local policy.
However, it is anticipated that local policies could involve making However, it is anticipated that local policies could involve making
different forwarding decisions in intermediary implementations, or different forwarding decisions in intermediary implementations, or
changing how the user is alerted or how identity is rendered in UA changing how the user is alerted or how identity is rendered in user
implementations. agent implementations.
8.3. Gateway Placement Services 8.3. Gateway Placement Services
The STIR 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 field, extract a could receive a call with an Identity header field, extract a
PASSporT from the Identity header field, and store that PASSporT at a PASSporT from the Identity header field, and store that PASSporT at a
CPS. 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
a PASSporT storage token (see Section 6.1). Per Step 3 of a PASSporT storage token (see Section 6.1). Per Step 3 of
Section 8.1 this may entail discovering several keys. The gateway Section 8.1, this may entail discovering several keys. The gateway
then collects the in-band PASSporT(s) from the in-band signaling, then collects the in-band PASSporT(s) from the in-band signaling,
encrypts the PASSporT(s), and stores them at the CPS. encrypts the 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 a rough example, we show a Call Placement Service implementation As a rough example, we show a CPS implementation here that uses a
here which uses a REST API to store and retrieve objects at the CPS. Representational State Transfer (REST) API to store and retrieve
The calling party stores the PASSporT at the CPS prior to initiating objects at the CPS. The calling party stores the PASSporT at the CPS
the call; the PASSporT is stored at a location at the CPS that prior to initiating the call; the PASSporT is stored at a location at
corresponds to the called number. Note that it is possible for the CPS that corresponds to the called number. Note that it is
multiple parties to be calling a number at the same time, and that possible for multiple parties to be calling a number at the same
for called numbers such as large call centers, many PASSporTs could time, and that for called numbers such as large call centers, many
legitimately be stored simultaneously, and it might prove difficult PASSporTs could legitimately be stored simultaneously, and it might
to correlate these with incoming calls. prove difficult 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.555.2222 (note that PASSporT for a call to the telephone number 2.222.555.2222 (note that
these are dummy values): these are dummy values):
eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9 eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9
jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJkZXN0Ijp7InRuIjpbI jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJkZXN0Ijp7InRuIjpbI
jIyMjI1NTUyMjIyIl19LCJpYXQiOiIxNTgzMjUxODEwIiwib3JpZyI6eyJ0biI6 jIyMjI1NTUyMjIyIl19LCJpYXQiOiIxNTgzMjUxODEwIiwib3JpZyI6eyJ0biI6
IjExMTE1NTUxMTExIn19.pnij4IlLHoR4vxID0u3CT1e9Hq4xLngZUTv45Vbxmd IjExMTE1NTUxMTExIn19.pnij4IlLHoR4vxID0u3CT1e9Hq4xLngZUTv45Vbxmd
3IVyZug4KOSa378yfP4x6twY0KTdiDypsereS438ZHaQ 3IVyZug4KOSa378yfP4x6twY0KTdiDypsereS438ZHaQ
skipping to change at line 1002 skipping to change at line 1003
Although the discussion above is written largely in terms of a single Although the discussion above is written largely in terms of a single
CPS, 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. Likely models include ones where a federation of the CPS function. Likely models include ones where a
carrier operates one or more CPS instances on behalf of its carrier operates one or more CPS instances on behalf of its
customers, enterprises run a CPS instance on behalf of their PBX customers, an enterprise runs a CPS instance on behalf of its PBX
users, or where third-party service providers offer a CPS as a cloud users, or a third-party service provider offers a CPS as a cloud
service. service.
Some service discovery possibilities under consideration include the Some service discovery possibilities under consideration include the
following: following:
For some deployments in closed (e.g. intranetwork) environments, For some deployments in closed (e.g., intra-network) environments,
the CPS location can simply be provisioned in implementations, the CPS location can simply be provisioned in implementations,
obviating the need for a discovery protocol. obviating the need for a discovery protocol.
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
link to the location of the CPS where PASSporTs should be stored a 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
[MODERN-TERI] protocol, could also serve for this application. Telephone-Related Information (TeRI) protocol [MODERN-TERI], could
also serve for this application.
Another possibility is to use a single distributed service for Another possibility is to use a single distributed service for
this function. VIPR [VIPR-OVERVIEW] proposed a RELOAD [RFC6940] this function. Verification Involving PSTN Reachability (VIPR)
usage for telephone numbers to help direct calls to enterprises on [VIPR-OVERVIEW] proposed a REsource LOcation And Discovery
the Internet. It would be possible to describe a similar RELOAD (RELOAD) [RFC6940] usage for telephone numbers to help direct
usage to identify the CPS where calls for a particular telephone calls to enterprises on the Internet. It would be possible to
number should be stored. One advantage that the STIR architecture describe a similar RELOAD usage to identify the CPS where calls
has over VIPR is that it assumes a credential system that proves for a particular telephone number should be stored. One advantage
authority over telephone numbers; those credentials could be used that the STIR architecture has over VIPR is that it assumes a
to determine whether or not a CPS could legitimately claim to be credential system that proves authority over telephone numbers;
the proper store for a given telephone number. those credentials could be used to determine whether or not a CPS
could legitimately claim to be the proper store for a given
telephone number.
This document does not prescribe any single way to do service 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 the location of the CPS at the Authentication Service and provision the location of the CPS at the authentication service and
Verification Service. verification service.
11. Encryption Key Lookup 11. Encryption Key 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 public encryption key. Note that because STIR access to the callee's public encryption key. Note that because STIR
uses ECDSA for signing PASSporTs, the public key used to verify uses the Elliptic Curve Digital Signature Algorithm (ECDSA) for
PASSporTs is not suitable for this function, and thus the encryption signing PASSporTs, the public key used to verify PASSporTs is not
key must be discovered separately. This requires some sort of suitable for this function, and thus the encryption key must be
directory/lookup system. discovered separately. This requires some sort of directory/lookup
system.
Some initial STIR deployments have fielded certificate repositories Some initial STIR deployments have fielded certificate repositories
so that verification services can acquire the signing credentials for so that verification services can acquire the signing credentials for
PASSporTs, which are linked through a URI in the "x5u" element of the PASSporTs, which are linked through a URI in the "x5u" element of the
PASSporT. These certificate repositories could clearly be repurposed PASSporT. These certificate repositories could clearly be repurposed
for allowing authentication services to download the public for allowing authentication services to download the public
encryption key for the called party - provided they can be discovered encryption key for the called party -- provided they can be
by calling parties. This document does not specify any particular discovered by calling parties. This document does not specify any
discovery scheme, but instead offers some general guidance about particular discovery scheme, but instead offers some general guidance
potential approaches. about potential approaches.
It is a desirable property that the public encryption key for a given It is a desirable property that the public encryption key for a given
party be linked to their STIR credential. An ECDH [RFC7748] public- party be linked to their STIR credential. An Elliptic Curve
private key pair might be generated for a subcert [TLS-SUBCERTS] of Diffie-Hellman (ECDH) [RFC7748] public-private key pair might be
the STIR credential. That subcert could be looked up along with the generated for a subcert [TLS-SUBCERTS] of the STIR credential. That
STIR credential of the called party. Further details of this subcert could be looked up along with the STIR credential of the
subcert, and the exact lookup mechanism involved, are deferred for called party. Further details of this subcert, and the exact lookup
future protocol work. mechanism involved, are deferred for future protocol work.
Obviously, if there is a single central database that the caller and Obviously, if there is a single central database that the caller and
callee each access in real time to download the other's keys, then callee each access in real time to download the other's keys, then
this represents a real privacy risk, as the central key database this represents a real privacy risk, as the central key database
learns about each call. A number of mechanisms are potentially learns about each call. A number of mechanisms are potentially
available to mitigate this: available to mitigate this:
Have endpoints pre-fetch keys for potential counterparties (e.g., Have endpoints pre-fetch keys for potential counterparties (e.g.,
their address book or the entire database). 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
keys they are fetching. keys they are fetching.
Clearly, there is a privacy/timeliness tradeoff in that getting up- Clearly, there is a privacy/timeliness trade-off in that getting up-
to-date knowledge about credential validity requires contacting the to-date knowledge about credential validity requires contacting the
credential directory in real-time (e.g., via OCSP [RFC2560]). This credential directory in real-time (e.g., via the Online Certificate
is somewhat mitigated for the caller's credentials in that he can get Status Protocol (OCSP) [RFC2560]). This is somewhat mitigated for
short-term credentials right before placing a call which only reveals the caller's credentials in that he can get short-term credentials
his calling rate, but not who he is calling. Alternately, the CPS right before placing a call which only reveals his calling rate, but
can verify the caller's credentials via OCSP, though of course this not who he is calling. Alternately, the CPS can verify the caller's
requires the callee to trust the CPS's verification. This approach credentials via OCSP, though of course this requires the callee to
does not work as well for the callee's credentials, but the risk trust the CPS's verification. This approach does not work as well
there is more modest since an attacker would need to both have the for the callee's credentials, but the risk there is more modest since
callee's credentials and regularly poll the database for every an attacker would need to both have the callee's credentials and
potential caller. regularly poll the database for every potential caller.
We consider the exact best point in the tradeoff space to be an open We consider the exact best point in the trade-off space to be an open
issue. issue.
12. Acknowledgments 12. IANA Considerations
The ideas in this document come out of discussions with Richard
Barnes and Cullen Jennings. We'd also like to thank Russ Housley,
Chris Wendt, Eric Burger, Mary Barnes, Ben Campbell, Ted Huang,
Jonathan Rosenberg, and Robert Sparks for helpful suggestions.
13. IANA Considerations
This memo includes no request to IANA. This document has no IANA actions.
14. Privacy Considerations 13. Privacy Considerations
Delivering PASSporTs out-of-band offers a different set of privacy Delivering PASSporTs out-of-band offers a different set of privacy
properties than traditional in-band STIR. In-band operations convey properties than traditional in-band STIR. In-band operations convey
PASSporTs as headers in SIP messages in cleartext, which any PASSporTs as headers in SIP messages in cleartext, which any
forwarding intermediaries can potentially inspect. By contrast, out- forwarding intermediaries can potentially inspect. By contrast, out-
of-band STIR stores these PASSporTs at a service after encrypting of-band STIR stores these PASSporTs at a service after encrypting
them as described in Section 6, effectively creating a path between them as described in Section 6, effectively creating a path between
the authentication and verification service in which the CPS is the the authentication and verification service in which the CPS is the
sole intermediary, but the CPS cannot read the PASSporTs. sole intermediary, but the CPS cannot read the PASSporTs.
Potentially, out-of-band PASSporT delivery could thus improve on the Potentially, out-of-band PASSporT delivery could thus improve on the
privacy story of STIR. privacy story of STIR.
The principle actors in the operation of out-of-band are the AS, VS, The principle actors in the operation of out-of-band are the AS, VS,
and CPS. The AS and VS functions differ from baseline [RFC8224] and CPS. The AS and VS functions differ from baseline behavior
behavior, in that they interact with an CPS over a non-SIP interface, [RFC8224], in that they interact with a CPS over a non-SIP interface,
of which the REST interface in Section 9 serves as an example. Some of which the REST interface in Section 9 serves as an example. Some
out-of-band deployments may also require a discovery service for the out-of-band deployments may also require a discovery service for the
CPS itself (Section 10) and/or encryption keys (Section 11). Even CPS itself (Section 10) and/or encryption keys (Section 11). Even
with encrypted PASSporTs, the network interactions by which the AS with encrypted PASSporTs, the network interactions by which the AS
and VS interact with the CPS, and to a lesser extent any discovery and VS interact with the CPS, and to a lesser extent any discovery
services, thus create potential opportunities for data leakage about services, thus create potential opportunities for data leakage about
calling and called parties. calling and called parties.
The process of storing and retrieving PASSporTs at a CPS can itself The process of storing and retrieving PASSporTs at a CPS can itself
reveal information about calls being placed. The mechanism takes reveal information about calls being placed. The mechanism takes
care not to require that the AS authenticate itself to the CPS, care not to require that the AS authenticate itself to the CPS,
relying instead on a blind signature mechanism for flood control relying instead on a blind signature mechanism for flood control
prevention. Section 7.4 discusses the practice of storing "dummy" prevention. Section 7.4 discusses the practice of storing "dummy"
PASSporTs at random intervals to thwart traffic analysis, and as PASSporTs at random intervals to thwart traffic analysis, and as
Section 8.2 notes, a CPS is required to return a dummy PASSporT even Section 8.2 notes, a CPS is required to return a dummy PASSporT even
if there is no PASSporT indexed for that calling number, which if there is no PASSporT indexed for that calling number, which
similarly enables the retrieval side to randomly request PASSporTs similarly enables the retrieval side to randomly request PASSporTs
when there are no calls in progress. These measures can help to when there are no calls in progress. These measures can help to
mitigiate information disclosure in the system. In implementations mitigate information disclosure in the system. In implementations
that require service discovery (see Section 10), perhaps through key that require service discovery (see Section 10), perhaps through key
discovery (Section 11), similar measures could be used to make sure discovery (Section 11), similar measures could be used to make sure
that service discovery does not itself disclose information about that service discovery does not itself disclose information about
calls. calls.
Ultimately, this document only provides a framework for future Ultimately, this document only provides a framework for future
implementation of out-of-band systems, and the privacy properties of implementation of out-of-band systems, and the privacy properties of
a given implementation will depend on architectural assumptions made a given implementation will depend on architectural assumptions made
in those environments. More closed systems for intranet operations in those environments. More closed systems for intranet operations
may adopt a weaker security posture but otherwise mitigate the risks may adopt a weaker security posture but otherwise mitigate the risks
of information disclosure, where more open environment will require of information disclosure, whereas more open environments will
careful implementation of the practices described here. require careful implementation of the practices described here.
For general privacy risks associated with the operations of STIR, For general privacy risks associated with the operations of STIR,
also see the Privacy Considerations of [RFC8224]. also see the privacy considerations covered in Section 11 of
[RFC8224].
15. 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 will vary depending on how the framework is applied and properties will vary depending on how the framework is applied and
deployed. General guidance for dealing with the most obvious deployed. General guidance for dealing with the most obvious
security challenges posed by this framework is given in Section 7.3 security challenges posed by this framework is given in Sections 7.3
and Section 7.4, along proposed solutions for problems like denial- and 7.4, along proposed solutions for problems like denial-of-service
of-service attacks or traffic analysis against the CPS. attacks or traffic analysis against the CPS.
Although there are considerable security challenges associated with Although there are considerable security challenges associated with
widespread deployment of a public CPS, those must be weighed against widespread deployment of a public CPS, those must be weighed against
the potential usefulness of a service that delivers a STIR assurance the potential usefulness of a service that delivers a STIR assurance
without requiring the passage of end-to-end SIP. Ultimately, the without requiring the passage of end-to-end SIP. Ultimately, the
security properties of this mechanism are at least comparable to in- security properties of this mechanism are at least comparable to in-
band STIR: the substitution attack documented in Section 7.4 could be band STIR: the substitution attack documented in Section 7.4 could be
implemented by any in-band SIP intermediary or eavesdropper who implemented by any in-band SIP intermediary or eavesdropper who
happened to see the PASSporT in transit, say, and launch its own call happened to see the PASSporT in transit, say, and launched its own
with a copy of that PASSporT to race against the original to the call with a copy of that PASSporT to race against the original to the
destination. destination.
16. Informative References 15. Informative References
[MODERN-TERI] [MODERN-TERI]
Peterson, J., "An Architecture and Information Model for Peterson, J., "An Architecture and Information Model for
Telephone-Related Information (TeRI)", Work in Progress, Telephone-Related Information (TeRI)", Work in Progress,
Internet-Draft, draft-ietf-modern-teri-00, 2 July 2018, Internet-Draft, draft-ietf-modern-teri-00, 2 July 2018,
<https://tools.ietf.org/html/draft-ietf-modern-teri-00>. <https://tools.ietf.org/html/draft-ietf-modern-teri-00>.
[PASSPORT-DIVERT] [PASSPORT-DIVERT]
Peterson, J., "PASSporT Extension for Diverted Calls", Peterson, J., "PASSporT Extension for Diverted Calls",
Work in Progress, Internet-Draft, draft-ietf-stir- Work in Progress, Internet-Draft, draft-ietf-stir-
skipping to change at line 1285 skipping to change at line 1284
<https://tools.ietf.org/html/draft-ietf-tls-subcerts-09>. <https://tools.ietf.org/html/draft-ietf-tls-subcerts-09>.
[VIPR-OVERVIEW] [VIPR-OVERVIEW]
Barnes, M., Jennings, C., Rosenberg, J., and M. Petit- Barnes, M., Jennings, C., Rosenberg, J., and M. Petit-
Huguenin, "Verification Involving PSTN Reachability: Huguenin, "Verification Involving PSTN Reachability:
Requirements and Architecture Overview", Work in Progress, Requirements and Architecture Overview", Work in Progress,
Internet-Draft, draft-jennings-vipr-overview-06, 9 Internet-Draft, draft-jennings-vipr-overview-06, 9
December 2013, <https://tools.ietf.org/html/draft- December 2013, <https://tools.ietf.org/html/draft-
jennings-vipr-overview-06>. jennings-vipr-overview-06>.
Acknowledgments
The ideas in this document came out of discussions with Richard
Barnes and Cullen Jennings. We'd also like to thank Russ Housley,
Chris Wendt, Eric Burger, Mary Barnes, Ben Campbell, Ted Huang,
Jonathan Rosenberg, and Robert Sparks for helpful suggestions.
Authors' Addresses 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
 End of changes. 97 change blocks. 
242 lines changed or deleted 248 lines changed or added

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