rfc8816xml2.original.xml   rfc8816.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!-- <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
vim:et:ts=2:sw=2:spell:spelllang=en:tw=80
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.ietf-modern-teri SYSTEM "http://xml.resource.org/public/rfc/bibxml3
/reference.I-D.ietf-modern-teri.xml">
<!ENTITY I-D.ietf-stir-passport-divert SYSTEM "http://xml.resource.org/public/rf
c/bibxml3/reference.I-D.ietf-stir-passport-divert.xml">
<!ENTITY I-D.ietf-tls-subcerts SYSTEM "http://xml.resource.org/public/rfc/bibxml
3/reference.I-D.ietf-tls-subcerts.xml">
<!ENTITY I-D.privacy-pass SYSTEM "http://xml.resource.org/public/rfc/bibxml3/ref
erence.I-D.privacy-pass.xml">
<!ENTITY I-D.jennings-vipr-overview SYSTEM "http://xml.resource.org/public/rfc/b
ibxml3/reference.I-D.jennings-vipr-overview.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2119.xml">
<!ENTITY RFC2560 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2560.xml">
<!ENTITY RFC5636 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5636.xml">
<!ENTITY RFC3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.3261.xml">
<!ENTITY RFC6116 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6116.xml">
<!ENTITY RFC6940 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6940.xml">
<!ENTITY RFC7340 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7340.xml">
<!ENTITY RFC7258 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7258.xml">
<!ENTITY RFC7748 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7748.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8174.xml">
<!ENTITY RFC8446 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8446.xml">
<!ENTITY RFC8224 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8224.xml">
<!ENTITY RFC8225 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8225.xml">
<!ENTITY RFC8226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8226.xml">
]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
<!--?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?--> number="8816"
<!-- used by XSLT processors --> docName="draft-ietf-stir-oob-07"
<!-- For a complete list and description of processing instructions (PIs), ipr="trust200902"
please see http://xml.resource.org/authoring/README.html. --> obsoletes=""
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds updates=""
might want to use. submissionType="IETF"
(Here they are set differently than their defaults in xml2rfc v1.32) --> category="info"
<!--?rfc strict="yes" ?--> consensus="true"
<!-- give errors regarding ID-nits and DTD validation --> xml:lang="en"
<!-- control the table of contents (ToC) --> tocInclude="true"
<?rfc toc="yes"?> tocDepth="4"
<!-- generate a ToC --> symRefs="true"
<?rfc tocdepth="4"?> sortRefs="true"
<!-- the number of levels of subsections in ToC. default: 3 --> version="3">
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="no" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ietf-stir-oob-07"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902
,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** --> <!-- xml2rfc v2v3 conversion 2.41.0 -->
<front> <front>
<!-- The abbreviated title is used in the page header - it is only necessary
if the
full title is longer than 39 characters -->
<title abbrev="STIR Out-of-Band">STIR Out-of-Band Architecture and Use Cases
</title>
<author fullname="Eric Rescorla" initials="E.K." surn <title abbrev="STIR Out-of-Band">Secure Telephone Identity Revisited (STIR)
ame="Rescorla"> Out-of-Band Architecture and Use Cases</title>
<seriesInfo name="RFC" value="8816"/>
<author fullname="Eric Rescorla" initials="E." surname="Rescorla">
<organization>Mozilla</organization> <organization>Mozilla</organization>
<address> <address>
<email>ekr@rtfm.com</email> <email>ekr@rtfm.com</email>
</address> </address>
</author> </author>
<author initials="J." surname="Peterson" fullname="Jon Peterson">
<author initials="J." surname="Peterson" fullname="Jon Peterson"> <organization abbrev="Neustar">Neustar, Inc.</organization>
<organization abbrev="Neustar">Neustar, Inc.</organization> <address>
<address> <postal>
<postal> <street>1800 Sutter St Suite 570</street>
<street>1800 Sutter St Suite 570</street> <city>Concord</city>
<city>Concord</city> <region>CA</region>
<region>CA</region> <code>94520</code>
<code>94520</code> <country>United States of America</country>
<country>US</country> </postal>
</postal> <email>jon.peterson@team.neustar</email>
<email>jon.peterson@team.neustar</email> </address>
</address> </author>
</author> <date month="August" year="2020"/>
<date year="2020" />
<!-- <area>
ART
</area>-->
<keyword>SIP</keyword> <keyword>SIP</keyword>
<abstract> <abstract>
<t> <t>The Personal Assertion Token (PASSporT) format defines
The PASSporT format defines a token that can be carried by signaling a token that can be carried by signaling protocols, including SIP,
protocols, including SIP, to cryptographically attest the identify of callers. to cryptographically attest the identity of callers.
Not all telephone calls use Internet signaling protocols, however However, not all telephone calls use Internet signaling protocols,
, and some calls use them for only part of their signaling path, or cannot relia and some calls use them for only part of their signaling
bly deliver SIP header fields end-to-end. path, while some cannot reliably deliver SIP header fields end-to-end.
This document describes use cases that require the delivery of PA This document describes use cases that require the delivery of
SSporT objects outside of the signaling path, and defines architectures and sema PASSporT objects outside of the signaling path, and defines
ntics to provide architectures and semantics to provide
this functionality. this functionality.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<t> <name>Introduction</name>
The STIR problem statement <xref target="RFC7340"/> describes widespread
problems enabled by impersonation in the telephone network, including illegal ro <t>The STIR problem statement <xref target="RFC7340" format="default"/>
bocalling, voicemail hacking, and swatting. describes widespread problems enabled by impersonation in the telephone network,
As telephone services are increasingly migrating onto the Internet, and u including illegal robocalling, voicemail hacking, and swatting.
sing Voice over IP (VoIP) protocols such as <xref target="RFC3261">SIP</xref>, i As telephone services are increasingly migrating onto the Internet,
t is necessary for these protocols and using Voice over IP (VoIP) protocols such as <xref target="RFC3261" format="
to support stronger identity mechanisms to prevent impersonation. For exa default">SIP</xref>,
mple, <xref target="RFC8224"/> defines a SIP Identity header field capable of ca it is necessary for these protocols to support stronger identity mechanisms to p
rrying <xref target="RFC8225">PASSporT</xref> objects in SIP as a means to crypt revent impersonation.
ographically attest that the originator of a telephone call is authorized to use For example, <xref target="RFC8224" format="default"/> defines a SIP Identity he
the calling party number (or, for native SIP cases, SIP URI) associated with th ader field
e originator of the call. capable of carrying <xref target="RFC8225" format="default">PASSporT objects</xr
</t><t> ef>
Not all telephone calls use SIP today, however, and even those that do us in SIP as a means to cryptographically attest that the originator of a
e SIP do not always carry SIP signaling end-to-end. telephone call is authorized to use the calling party number (or, for native SIP
cases,
SIP URI) associated with the originator of the call.
</t>
<t>Not all telephone calls use SIP today, however, and even those that do
use SIP do not always carry SIP signaling end-to-end.
Calls from telephone numbers still routinely traverse the Public Switched Tel ephone Network (PSTN) at some Calls from telephone numbers still routinely traverse the Public Switched Tel ephone Network (PSTN) at some
point. Broadly, calls fall into one of three categories: point. Broadly, calls fall into one of three categories:
</t><t><list style="numbers"><t> </t>
<ol spacing="normal" type="1">
<li>
One or both of the endpoints is actually a PSTN endpoint. One or both of the endpoints is actually a PSTN endpoint.
</t><t> </li>
Both of the endpoints are non-PSTN (SIP, Jingle, ...) but the call <li>Both of the endpoints are non-PSTN (SIP, Jingle, etc.) but the call
transits the PSTN at some point. transits the PSTN at some point.
</t><t> </li>
Non-PSTN calls which do not transit the PSTN at all (such as native SIP e <li>Non-PSTN calls that do not transit the PSTN at all (such as native S
nd-to-end calls). IP end-to-end calls).
</t></list></t><t> </li>
The first two categories represent the majority of telephone calls assoc </ol>
iated with problems like illegal robocalling: many robocalls today originate on <t>The first two categories represent the majority of telephone calls ass
the Internet but terminate at PSTN endpoints. ociated with problems like illegal robocalling: many robocalls today originate o
n the Internet but terminate at PSTN endpoints.
However, the core network elements that operate the PSTN are legacy devices t hat However, the core network elements that operate the PSTN are legacy devices t hat
are unlikely to be upgradable at this point to support an in-band authenticat ion system. are unlikely to be upgradable at this point to support an in-band authenticat ion system.
As such, those devices largely cannot be modified to pass signatures originat As such, those devices largely cannot be modified to pass signatures originat
ing on the Internet--or indeed any inband signaling ing on the Internet -- or indeed any in-band signaling
data--intact. Even if fields for tunneling arbitrary data can be found in tr data -- intact. Even if fields for tunneling arbitrary data can be found in
aditional PSTN signaling, in some cases legacy elements would strip the signatur traditional PSTN signaling, in some cases legacy elements would strip the signat
es from those fields; in ures from those fields; in
others, they might damage them to the point where they cannot be others, they might damage them to the point where they cannot be
verified. For those first two categories above, any in-band authentication s cheme does not verified. For those first two categories above, any in-band authentication s cheme does not
seem practical in the current environment. seem practical in the current environment.
</t><t> </t>
While the core network of the PSTN remains fixed, the endpoints of <t>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 being replaced by three classes of intelligent devices: smart
phones, IP PBXs, and terminal adapters. All three are general phones, IP Private Branch Exchanges (PBXs), and terminal adapters. All three are general
purpose computers, and typically all three have Internet access as purpose computers, and typically all three have Internet access as
well as access to the PSTN; they may be used for residential, mobile, or ente rprise telephone services. well as access to the PSTN; they may be used for residential, mobile, or ente rprise telephone services.
Additionally, various kinds of gateways increasingly front for Additionally, various kinds of gateways increasingly front for
deployments of legacy PBX and PSTN switches. All of this provides a potential avenue for deployments of legacy PBX and PSTN switches. All of this provides a potential avenue for
building an authentication system that implements stronger identity while lea ving PSTN systems intact. building an authentication system that implements stronger identity while lea ving PSTN systems intact.
</t><t> </t>
This capability also provides an ideal transitional technology while in-b <t> This capability also provides an ideal transitional technology while i
and STIR adoption is ramping up. It permits early adopters to use the technology n-band STIR adoption is ramping up. It permits early adopters to use the technol
even when intervening network ogy even when intervening network
elements are not yet STIR-aware, and through various kinds of gateways, i elements are not yet STIR-aware, and through various kinds of gateways, it may a
t may allow providers with a significant PSTN investment to still secure their c llow providers with a significant PSTN investment to still secure their calls wi
alls with STIR. th STIR.
</t><t> </t>
The techniques described in this document therefore build on the <xref ta <t>The techniques described in this document therefore build on the
rget="RFC8225">PASSporT</xref> mechanism and the work of <xref target="RFC8224"/ <xref target="RFC8225" format="default">PASSporT</xref> mechanism and the work o
> to describe a way that f <xref target="RFC8224" format="default"/> to describe a way that
a PASSporT object created in the originating network of a call can reach a PASSporT object created in the originating network of a call can reach the ter
the terminating network even when it cannot be carried end-to-end in-band in the minating network even when it cannot be carried end-to-end in-band in the call s
call signaling. This relies on ignaling. This relies on
a new service defined in this document called a Call Placement Service (C a new service defined in this document called a Call Placement Service (CPS) tha
PS) that permits the PASSporT object to be stored during call processing and ret t permits the PASSporT object to be stored during call processing and retrieved
rieved for verification purposes. for verification purposes.
</t><t> </t>
Potential implementors should note that this document merely defines the <t>Potential implementors should note that this document merely defines th
operating environments in which this e operating environments in which this
out-of-band STIR mechanism is intended to operate. It provides use case out-of-band STIR mechanism is intended to operate. It provides use cases
s, gives a broad description of the components and a potential solution architec , gives a broad description of the components, and a potential solution architec
ture. ture.
Various environments may have their own security requirements: a Various environments may have their own security requirements: a public deployme
public deployment of out-of-band STIR faces far greater challenges than a constr nt of out-of-band STIR faces far greater challenges than a constrained intra-net
ained work deployment.
intranetwork deployment.
To flesh out the storage and retrieval of PASSporTs in the CPS within th is To flesh out the storage and retrieval of PASSporTs in the CPS within th is
context, this document includes a strawman protocol suitable for that pu rpose. Deploying this framework in any given environment context, this document includes a strawman protocol suitable for that pu rpose. Deploying this framework in any given environment
would require additional specification outside the scope of the current would require additional specification outside the scope of this documen
document. t.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Terminology"> <name>Terminology</name>
<t>TThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"OPTIONAL" in this document are to be interpreted as described in IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and o NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
nly when, they appear in all RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Operating Environments"> <name>Operating Environments</name>
<t> <t>This section describes the environments in which the proposed out-of-ba
This section describes the environments in which the proposed out-of nd STIR mechanism is intended to operate. In the simplest setting, Alice
-band STIR calls Bob, and her call is routed through some set of gateways and/or the PST
mechanism is intended to operate. In the simplest setting, Alice is N
calling Bob, and her call is routed through some set of gateways and/or the P that do not support end-to-end delivery of STIR. Both Alice
STN and Bob have smart devices that can access the Internet (perhaps enterprise d
which do not support end-to-end delivery of STIR. Both Alice evices, or even end-user ones), but they do not have
and Bob have smart devices which can access the Internet (perhaps enterprise
devices, or even end user ones), but they do not have
a clear telephone signaling connection between them: Alice cannot inject any data into a clear telephone signaling connection between them: Alice cannot inject any data into
signaling which Bob can read, with the exception of the asserted destination signaling that Bob can read, with the exception of the asserted destination a
and origination nd origination
E.164 numbers. The calling party number might originate from her own device o E.164 numbers. The calling party number might originate from her own device o
r from the network. These numbers are effectively the only data that can be use r from the network. These numbers are effectively the only data that can be use
d for coordination between d for coordination between the endpoints.
the endpoints. </t>
</t> <artwork name="" type="" align="left" alt=""><![CDATA[
<figure> +---------+
<artwork><![CDATA[ / \
+---------+ +--- +---+
/ \ +----------+ / \ +----------+
+--- +---+ | | | Gateways | | |
+----------+ / \ +----------+ | Alice |<----->| and/or |<----->| Bob |
| | | Gateways | | | | (caller) | | PSTN | | (callee) |
| Alice |<----->| and/or |<----->| Bob | +----------+ \ / +----------+
| (caller) | | PSTN | | (callee) | +--- +---+
+----------+ \ / +----------+ \ /
+--- +---+ +---------+
\ / ]]></artwork>
+---------+ <t>In a more complicated setting, Alice and/or Bob may not have a smart or
]]></artwork>
</figure>
<t>
In a more complicated setting, Alice and/or Bob may n
ot have a smart or
programmable device, but instead just a traditional telephone. However, one o r both of them are behind a STIR-aware gateway that can participate in out-of-ba nd coordination, as shown below: programmable device, but instead just a traditional telephone. However, one o r both of them are behind a STIR-aware gateway that can participate in out-of-ba nd coordination, as shown below:
</t> </t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure> +---------+
<artwork><![CDATA[ / \
+---------+ +--- +---+
/ \ +----------+ +--+ / \ +--+ +----------+
+--- +---+ | | | | | Gateways | | | | |
+----------+ +--+ / \ +--+ +----------+ | Alice |<-|GW|->| and/or |<-|GW|->| Bob |
| | | | | Gateways | | | | | | (caller) | | | | PSTN | | | | (callee) |
| Alice |<-|GW|->| and/or |<-|GW|->| Bob | +----------+ +--+ \ / +--+ +----------+
| (caller) | | | | PSTN | | | | (callee) | +--- +---+
+----------+ +--+ \ / +--+ +----------+ \ /
+--- +---+ +---------+
\ / ]]></artwork>
+---------+ <t>In such a case, Alice might have an analog (e.g., PSTN) connection to h
]]></artwork> er
</figure> gateway or switch that is responsible for her identity. Similarly, the gatew
ay
<t>
In such a case, Alice might have an analog (e.g., PSTN) conne
ction to her gateway/
switch which is responsible for her identity. Similarly, the gateway
would verify Alice's identity, generate the right calling party number would verify Alice's identity, generate the right calling party number
information and provide that number to Bob using ordinary information, and provide that number to Bob using ordinary
Plain Ol' Telephone Service (POTS) mechanisms. Plain Old Telephone Service (POTS) mechanisms.
</t> </t>
</section> </section>
<section anchor="data" numbered="true" toc="default">
<section anchor="data" title="Dataflows"> <name>Dataflows</name>
<t>Because in these operating environments endpoints cannot pass cryptogra <t>Because in these operating environments, endpoints cannot pass cryptogr
phic information to one another directly aphic information to one another directly
through signaling, any solution must through signaling, any solution must
involve some rendezvous mechanism to allow endpoints to communicate. involve some rendezvous mechanism to allow endpoints to communicate.
We call this rendezvous service a "call placement service" (CPS), a service w here a record of call placement, We call this rendezvous service a Call Placement Service (CPS), a service whe re 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 minimally we principle, this service could communicate any information, but minimally we
expect it to include a full-form PASSporT that attests 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 of existence of a PASSporT for a given incoming call as rough validation of
the asserted origin of that call. (See <xref target="lookup"/> for limitatio ns of the asserted origin of that call. (See <xref target="lookup" format="default "/> for limitations of
this design.) this design.)
</t><t> </t>
This architecture does not mandate that any particular sort of entity ope <t>This architecture does not mandate that any particular sort
rate a CPS, or mandate any means to discover a CPS. A CPS of entity operate a CPS or mandate any means to discover a CPS. A CPS
could be run internally within a network, or made publicly available. One could be run internally within a network or made publicly available.
or more CPSes could be run by a carrier, as repositories for PASSporTs One or more CPSes could be run by a carrier, as repositories for PASSporTs
for calls sent to its customers, or a CPS could be built-in to an enterpr for calls sent to its customers, or a CPS could be built into an enterprise
ise PBX, or even a smartphone. To the degree possible, it is PBX or even a smartphone. To the degree possible, it is
specified here generically, as an idea that may have applicability to a v specified here generically as an idea that may have applicability to a variety o
ariety of STIR deployments. f STIR deployments.
</t><t> </t>
There are roughly two plausible dataflow architectures for the CPS: <t>There are roughly two plausible dataflow architectures for the CPS:
</t><t><list style="numbers"><t> </t>
The callee registers with the CPS. When the caller wishes to
<ol spacing="normal" type="1">
<li>The callee registers with the CPS. When the caller wishes to
place a call to the callee, it sends the PASSporT to the CPS, which immedi ately place a call to the callee, it sends the PASSporT to the CPS, which immedi ately
forwards it to the callee, or, forwards it to the callee.
</t><t> </li>
The caller stores the PASSporT with the CPS at the time of call <li>The caller stores the PASSporT with the CPS at the time of call
placement. When the callee receives the call, it contacts the CPS placement. When the callee receives the call, it contacts the CPS
and retrieves the PASSporT. and retrieves the PASSporT.
</t></list></t><t> </li>
While the first architecture is roughly isomorphic to current VoIP </ol>
<t>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 endpoints had the capabilities and is especially problematic for mobile endpoints. Indeed, if the endpoints had the capabilities
to implement such an architecture, they could surely just use SIP or some oth er to implement such an architecture, they could surely just use SIP or some oth er
protocol to set up a secure session; even if the media were going through the traditional PSTN, a protocol to set up a secure session; even if the media were going through the traditional PSTN, a
"shadow" SIP session could convey the PASSporT. Thus, we focus "shadow" SIP session could convey the PASSporT. Thus, we focus
on the second architecture in which the PSTN incoming call serves as on the second architecture in which the PSTN incoming call serves as
the notification channel and the callee can then contact the CPS to the notification channel, and the callee can then contact the CPS to
retrieve the PASSporT. In specialized environments, for example a call center retrieve the PASSporT. In specialized environments, for example, a call cente
that receives a large volume of r that receives a large volume of
incoming calls that originated in the PSTN, the notification channel approach might be viable. incoming calls that originated in the PSTN, the notification channel approach might be viable.
</t> </t>
</section> </section>
<section anchor="uses" numbered="true" toc="default">
<section anchor="uses" title="Use Cases"> <name>Use Cases</name>
<t> <t>The following are the motivating use cases for this mechanism. Bear in
The following are the motivating use cases for this mechanism. Bear in mi mind that,
nd that just as in <xref target="RFC8224"/> there may be multiple Identity heade just as in <xref target="RFC8224" format="default"/>, there may be multiple Iden
rs in a single SIP tity header fields in a single SIP
INVITE, so there may be multiple PASSporTs in this out-of-band mechanism INVITE, so there may be multiple PASSporTs in this out-of-band mechanism associa
associated with a single call. For example, a SIP user agent might create a PASS ted with a single call. For example, a SIP user agent might create a PASSporT fo
porT for a call with an end user r a call with an end-user
credential, and as the call exits the originating administrative domain t credential, and as the call exits the originating administrative domain,
he network authentication service might create its own PASSporT for the same cal the network authentication service might create its own PASSporT for the same ca
l. As such, these use cases may overlap ll. As such, these use cases may overlap
in the processing of a single call. in the processing of a single call.
</t> </t>
<section anchor="case-ip-pstn" title="Case 1: VoIP to PSTN Call"> <section anchor="case-ip-pstn" numbered="true" toc="default">
<t> <name>Case 1: VoIP to PSTN Call</name>
A call originates in a SIP environment in a STIR-aware administra <t>A call originates in a SIP environment in a STIR-aware administrative
tive domain. The local authentication service for that administrative domain cre domain. The local authentication service for that administrative domain creates
ates a PASSporT which is carried a PASSporT that is carried
in band in the call per <xref target="RFC8224"/>. The call is rou in band in the call per <xref target="RFC8224" format="default"/>. The call is r
ted out of the originating administrative domain and reaches a gateway to the PS outed out of the originating administrative domain and reaches a gateway to the
TN. PSTN.
Eventually, the call will terminate on a mobile smartphone that s Eventually, the call will terminate on a mobile smartphone that supports this ou
upports this out-of-band mechanism. t-of-band mechanism.
</t><t> </t>
In this use case, the originating authentication service can store t <t>In this use case, the originating authentication service
he PASSporT with the appropriate CPS (per the practices of can store the PASSporT with the appropriate CPS (per the practices of
<xref target="cps"/>) for the target telephone number as a fallback <xref target="cps" format="default"/>) for the target telephone number
in case SIP signaling will not as a fallback in case SIP signaling will not reach end-to-end. When
reach end-to-end. When the destination mobile smartphone receives the destination mobile smartphone receives the call over the PSTN, it
the call over the PSTN, it consults the CPS and discovers a PASSporT from the o consults the CPS and discovers a PASSporT from the originating telephone number
riginating telephone number waiting for it. waiting for it.
It uses this PASSporT to verify the calling party number. It uses this PASSporT to verify the calling party number.
</t> </t>
</section> </section>
<section anchor="case-pstn-pstn-gw" title="Case 2: Two Smart PSTN <section anchor="case-pstn-pstn-gw" numbered="true" toc="default">
endpoints"> <name>Case 2: Two Smart PSTN Endpoints</name>
<t> <t>A call originates with an enterprise PBX that has both
A call originates with an enterprise PBX that has both Internet a Internet access and a built-in gateway to the PSTN, which communicates
ccess and a built-in gateway to the PSTN, which communicates through traditional through traditional telephone signaling protocols.
telephone signaling protocols. The PBX immediately routes the call to the PSTN, The PBX immediately routes the call to the PSTN, but before it does,
but before it does, it provisions it provisions a PASSporT on the CPS associated with the target telephone number.
a PASSporT on the CPS associated with the target telephone number </t>
. <t>After normal PSTN routing, the call lands on a smart mobile handset t
</t><t> hat supports the STIR out-of-band mechanism. It queries the appropriate CPS over
After normal PSTN routing, the call lands on a smart mobile hands the Internet to determine if a call has been placed to it
et that supports the STIR out-of-band mechanism. It queries the appropriate CPS by a STIR-aware device. It finds the PASSporT provisioned by the
over the Internet to determine if a call has been placed to it enterprise PBX and uses it to verify the calling party number.
by a STIR-aware device. It finds the PASSporT provisioned by the </t>
enterprise PBX and uses it to verify the calling party number. </section>
</t> <section anchor="case-pstn-ip" numbered="true" toc="default">
</section> <name>Case 3: PSTN to VoIP Call</name>
<section anchor="case-pstn-ip" title="Case 3: PSTN to VoIP Call"> <t>A call originates with an enterprise PBX that has both
<t> Internet access and a built-in gateway to the PSTN. It will immediately
A call originates with an enterprise PBX that has both Internet a route the call to the PSTN, but before it does, it provisions
ccess and a built-in gateway to the PSTN. It will immediately route the call to a PASSporT with the CPS associated with the target telephone number.
the PSTN, but before it does, it provisions However, it turns out that the call will eventually route through
a PASSporT with the CPS associated with the target telephone numb the PSTN to an Internet gateway, which will translate this into a SIP
er. However, it turns out that the call will eventually route through the PSTN t call and deliver it to an administrative domain with a STIR verification service
o an Internet gateway, which will translate this into a SIP .
call and deliver it to an administrative domain with a STIR verif </t>
ication service. <t>In this case, there are two subcases for how the PASSporT
</t><t> might be retrieved. In subcase 1, the Internet gateway that receives
In this case, there are two subcases for how the PASSporT might b the call from the PSTN could query the appropriate CPS to determine
e retrieved. In subcase 1, if the original caller created and provisioned a PASSporT for this call. If so,
the Internet gateway that receives the call from the PSTN could q it can retrieve the PASSporT and, when it creates a SIP INVITE for
uery the appropriate CPS to determine if the original caller created and provisi this call, add a corresponding Identity header field per
oned a PASSporT for this call. If so, <xref target="RFC8224" format="default"/>. When the SIP INVITE reaches
it can retrieve the PASSporT and, when it creates a SIP INVITE fo the destination administrative domain, it will be able to verify the
r this call, add a corresponding Identity header field per <xref target="RFC8224 PASSporT normally. Note that to avoid discrepancies with the Date
"/>. When the SIP INVITE reaches header field value, only a full-form PASSporT should be used for this purpose. I
the destination administrative domain, it will be able to verify n
the PASSporT normally. Note that to avoid discrepancies with the Date header fie subcase 2, the gateway does not retrieve the PASSporT itself, but
ld value, only full-form PASSporT should be used for this purpose. In instead the verification service at the destination administrative
subcase 2, the gateway does not retrieve the PASSporT itself, but domain does so. Subcase 1 would perhaps be valuable for deployments where
instead the verification service at the destination administrative domain does the destination administrative domain supports in-band STIR but not out-of-band
so. Subcase 1 would perhaps be valuable for deployments where STIR.
the destination administrative domain supports in-band STIR but n </t>
ot out-of-band STIR. </section>
</t> <section anchor="case-gateways" numbered="true" toc="default">
</section> <name>Case 4: Gateway Out-of-Band</name>
<section anchor="case-gateways" title="Case 4: Gateway Out-of-ban <t>A call originates in the SIP world in a STIR-aware administrative dom
d"> ain.
<t> The local authentication service for that administrative domain creates a PASSpo
A call originates in the SIP world in a STIR-aware administrative rT that is carried
domain. The local authentication service for that administrative domain creates in band in the call per <xref target="RFC8224" format="default"/>. The call is r
a PASSporT which is carried outed
in band in the call per <xref target="RFC8224"/>. The call is rou out of the originating administrative domain and eventually reaches a gateway to
ted out of the originating administrative domain and eventually reaches a gatewa the PSTN.
y to the PSTN. </t>
</t><t> <t>In this case, the originating authentication service does not support
In this case, the originating authentication service does not sup the out-of-band mechanism, so instead the gateway to the PSTN extracts the PASS
port the out-of-band mechanism, so instead the gateway to the PSTN extracts the porT from the SIP request and provisions it to the CPS. (When the call reaches t
PASSporT from the SIP request and provisions it to the CPS. (When the call reach he gateway to the PSTN, the gateway might first check the CPS to see if a PASSpo
es the gateway to the PSTN, the gateway might first check the CPS to see if a PA rT object had already been provisioned for this call, and only provision a PASSp
SSporT object had already been provisioned for this call, and only provision a P orT if none is present).
ASSporT if none is present). </t>
</t><t> <t>Ultimately, the call may terminate on the PSTN or be routed back to a
Ultimately, the call may terminate on the PSTN, or be routed back SIP environment. In the former case, perhaps the destination endpoint queries t
to a SIP environment. In the former case, perhaps the destination endpoint quer he CPS to retrieve the PASSporT provisioned by the first gateway. If the call ul
ies the CPS to retrieve the PASSporT provisioned by the first gateway. Or if the timately returns to a SIP environment, it might be the gateway from the PSTN bac
call ultimately returns to a SIP environment, it might be the gateway from the k to the Internet that retrieves the PASSporT from the CPS and attaches it to th
PSTN back to the Internet that retrieves the PASSporT from the CPS and attaches e new SIP INVITE it creates, or it might be the terminating administrative domai
it to the new SIP INVITE it creates, or it might be the terminating administrati n's verification service that checks the CPS when an INVITE arrives with no Iden
ve domain's verification service that checks the CPS when an INVITE arrives with tity header field. Either way, the PASSporT can survive the gap in SIP coverage
no Identity header field. Either way the PASSporT can survive the gap in SIP co caused by the PSTN leg of the call.
verage caused by the PSTN leg of the call. </t>
</t> </section>
</section> <section anchor="case-enterprise" numbered="true" toc="default">
<section anchor="case-enterprise" title="Case 5: Enterprise Call <name>Case 5: Enterprise Call Center</name>
Center"> <t>A call originates from a mobile user, and a STIR authentication servi
<t> ce operated by their carrier creates a PASSporT for the call. As the carrier for
A call originates from a mobile user, and a STIR authentication s wards the call via SIP, it attaches the PASSporT to the SIP call with an Identit
ervice operated by their carrier creates a PASSporT for the call. As the carrier y header field. As a fallback in case the call will not go end-to-end over SIP,
forwards the call via SIP, it attaches the PASSporT to the SIP call with an Ide the carrier also stores the PASSporT in a CPS.
ntity header field. As a fallback in case the call will not go end-to-end over S </t>
IP, the carrier also stores the PASSporT in a CPS. <t>The call is then routed over SIP for a time, before it
</t><t> transitions to the PSTN and ultimately is handled by a legacy PBX at a
The call is then routed over SIP for a time, before it transition high-volume call center. The call center supports the out-of-band service,
s to the PSTN and ultimately is handled by a legacy PBX at a high-volume call ce and has a high-volume interface to a CPS to retrieve PASSporTs for incoming
nter. The call center supports the out-of-band service, and has a high-volume in calls; agents at the call center use a general purpose computer to manage
terface to a CPS to retrieve PASSporTs for incoming calls; agents at the call ce inbound calls and can receive STIR notifications through it. When the PASSporT
nter use a general purpose computer to manage inbound calls and can receive STIR arrives at the CPS, it is sent through a subscription/notification interface
notifications through it. When the PASSporT arrives at the CPS, it is sent thro to a system that can correlate incoming calls with valid PASSporTs. The call
ugh a subscription/notification interface to a system that can correlate incomin center agent sees that a valid call from the originating number has arrived.
g calls with valid PASSporTs. The call center agent sees that a valid call from </t>
the originating number has arrived. </section>
</t> </section>
</section> <section anchor="authz" numbered="true" toc="default">
<name>Storing and Retrieving PASSporTs</name>
</section> <t>The use cases show a variety of entities accessing the CPS to
store and retrieve PASSporTs. The question of how the CPS authorizes the
<section anchor="authz" title="Storing and Retrieving PASSporTs"> storage and retrieval of PASSporTs is thus a key design decision in the architec
<t>The use cases show a variety of entities accessing the CPS to store and ture.
retrieve PASSporTs. The question of how the CPS authorizes the storage The STIR architecture assumes that service providers and, in some cases,
and retrieval of PASSporT is thus a key design decision in the architec end-user devices will have credentials suitable for attesting authority
ture. over telephone numbers per <xref target="RFC8226" format="default"/>.
The STIR architecture assumes that service providers and in some cases These credentials provide the most obvious way that a CPS can authorize
end user devices will have credentials suitable for attesting authority over tel the storage and retrieval of PASSporTs. However, as use cases 3, 4, and 5
ephone numbers per <xref target="RFC8226"/>. in <xref target="uses" format="default"/> show, it may sometimes make sense
These credentials provide the most obvious way that a CPS can authorize for the entity storing or retrieving PASSporTs to be an intermediary rather
the storage and retrieval of PASSporTs. However, as use cases 3, 4 and 5 in <xr than a device associated with either the originating or terminating side of
ef target="uses"/> show, it may sometimes make sense for the entity a call; those intermediaries often would not have access to STIR
storing or retrieving PASSporTs to be an intermediary rather than a dev credentials covering the telephone numbers in question. Requiring authorization
ice associated with either the originating or terminating side of a call, and th based on a credential to store PASSporTs is therefore undesirable, though
ose intermediaries often would not have access to STIR credentials covering the potentially acceptable if sufficient steps are taken to mitigate any privacy
telephone numbers in question. Requiring authorization based on a credential to risk of leaking data.
store PASSporTs is therefore undesirable, though potentially acceptable if suffi </t>
cient steps are taken to mitigate any privacy risk of leaking data. <t>It is an explicit design goal of this mechanism to minimize
</t><t> the potential privacy exposure of using a CPS. Ideally, the out-of-band
It is an explicit design goal of this mechanism to minimize the potenti mechanism should not result in a worse privacy situation than in-band
al privacy exposure of using a CPS. Ideally, the out-of-band STIR <xref target="RFC8224" format="default"/>: for in-band, we might say
mechanism should not result in a worse privacy situation than in-band < that a SIP entity is authorized to receive a PASSporT if it is an intermediate
xref target="RFC8224"/> STIR: for in-band, we might say that a SIP entity is aut or final target of the routing of a SIP request. As the originator of a
horized to receive a PASSporT if it call cannot necessarily predict the routing path a call will follow, an
is an intermediate or final target of the routing of a SIP request. As out-of-band mechanism could conceivably even improve on the privacy story.
the originator of a call cannot necessarily predict the routing path a call will </t>
follow, an out-of-band mechanism could conceivably <t>Broadly, the architecture recommended here thus is one focused
even improve on the privacy story. on permitting any entity to store encrypted PASSporTs at the CPS, indexed
</t><t> under the called number. PASSporTs will be encrypted with a public key
Broadly, the architecture recommended here thus is one focused on permi associated with the called number, so these PASSporTs may safely be retrieved
tting any entity to store by any entity because only holders of the corresponding private key will be
encrypted PASSporTs at the CPS, indexed under the called number. PASSpo able to decrypt the PASSporT. This also prevents the CPS itself from
rTs will be encrypted with a public key associated with the called number, so th learning the contents of PASSporTs, and thus metadata about calls in
ese PASSporTs may safely be retrieved by any entity, as progress, which makes the CPS a less attractive target for pervasive
only holders of the corresponding private key will be able to decrypt t monitoring (see <xref target="RFC7258" format="default"/>). As a first
he PASSporT. This also prevents the CPS itself from learning the contents of PA step, transport-level security can provide confidentiality from eavesdroppers
SSporTs, and thus metadata about calls in progress, which makes the CPS a less a for both the storing and retrieval of PASSporTs. To bolster the privacy story,
ttractive target for pervasive monitoring (see <xref target="RFC7258"/>). As a f to prevent denial-of-service flooding of the CPS, and to complicate traffic
irst step, transport-level security can provide confidentiality from eavesdroppe analysis, a few additional mechanisms are also recommended below.
rs for both the storing and retrieval of PASSporTs. To bolster the privacy story </t>
, prevent denial-of-service flooding of the CPS, and to complicate traffic analy <section anchor="stor" numbered="true" toc="default">
sis, a few additional mechanisms are also recommended below. <name>Storage</name>
<t>There are a few dimensions to authorizing the storage of PASSporTs.
</t> Encrypting PASSporTs prior to storage entails that a CPS has no way to tell
<section anchor="stor" title="Storage"> if a PASSporT is valid; it simply conveys encrypted blocks that it cannot
<t> access itself and can make no authorization decision based on the PASSporT
There are a few dimensions to authorizing the storage of PASSporTs. Enc contents. There is certainly no prospect for the CPS to verify the PASSporTs its
rypting PASSporTs prior to storage entails that a CPS has no way to tell if a PA elf.
SSporT is valid; it simply conveys encrypted </t>
blocks that it cannot access itself, and can make no authorization deci <t>Note that this architecture requires clients that store PASSporTs
sion based on the PASSporT contents. There is certainly no prospect for the CPS to have access to an encryption key associated with the intended called party
to verify the PASSporTs itself. to be used to encrypt the PASSporT. Discovering this key requires the existence
</t><t> of a key lookup service (see <xref target="lookup" format="default"/>),
Note that this architecture requires clients that store PASSporTs to ha depending on how the CPS is architected; however, some kind of key store or
ve access to an encryption key associated with the intended called party to be u repository could be implemented adjacent to it and perhaps even incorporated
sed to encrypt the PASSporT. Discovering this key requires the existence of a ke into its operation. Key discovery is made more complicated by the fact that
y lookup service (see <xref target="lookup"/>); depending on how the CPS is arch there can potentially be multiple entities that have
itected, however, some kind of key store or repository could be implemented adja authority over a telephone number: a carrier, a reseller, an enterprise,
cent to it, and perhaps even incorporated into its operation. Key discovery is m and an end user might all have credentials permitting them to attest that they
ade more complicated by the fact that there can potentially be multiple entities are allowed to originate calls from a number, say. PASSporTs for out-of-band use
that have therefore might need to be encrypted with multiple keys in the hopes that one
authority over a telephone number: a carrier, a reseller, an enterprise will be decipherable by the relying party.
, and an end user might all have credentials permitting them to attest that they </t>
are allowed to originate calls from a number, say. PASSporTs for out-of-band us <t>Again, the most obvious way to authorize storage is to require
e therefore might need to be encrypted with multiple keys in the hopes that one the originator to authenticate themselves to the CPS with their STIR credential.
will be decipherable by the relying party. However, since the call is indexed at the CPS under the called number,
</t><t> this can weaken the privacy story of the architecture, as it reveals to
Again, the most obvious way to authorize storage is to require the orig the CPS both the identity of the caller and the callee. Moreover, it does not wo
inator to authenticate themselves to the CPS with their STIR credential. However rk
, since the call is indexed at the CPS under the called number, this can weaken for the gateway use cases described above; to support those use cases, we must
the privacy story of the architecture, as it reveals to the CPS both the identit effectively allow any entity to store PASSporTs at a CPS. This does not degrade
y of the caller and the callee. Moreover, it does not work for the gateway use c the anti-impersonation security of STIR, because entities who do not possess
ases described above; to support those use cases, we must effectively allow any the necessary credentials to sign the PASSporT will not be able to create
entity to store PASSporTs at a CPS. This does not degrade the anti-impersonation PASSporTs that will be treated as valid by verifiers. In this architecture,
security of STIR, because entities who do not possess the necessary credentials it does not matter whether the CPS received a PASSporT from the authentication
to sign the PASSporT will not be able to create PASSporTs that will be treated service that created it or from an intermediary gateway downstream in the
as valid by verifiers. In this architecture, it does not matter whether the CPS routing path as in case 4 above. However, if literally anyone can store
received a PASSporT from the authentication service that created it or from an i PASSporTs in the CPS, an attacker could easily flood the CPS with millions
ntermediary gateway downstream in the routing path as in case 4 above. However, of bogus PASSporTs indexed under a calling number, and thereby prevent the calle
if literally anyone can store PASSporTs in the CPS, an attacker could easily flo d
od the CPS with millions of bogus PASSporTs indexed under a calling number, and party from finding a valid PASSporT for an incoming call buried in a haystack of
thereby prevent the called fake entries.
party from finding a valid PASSporT for an incoming call buried in a ha </t>
ystack of fake entries. <t>The solution architecture must therefore include some sort of traffic
</t><t> control system to prevent flooding. Preferably, this should not require
The solution architecture must therefore include some sort of traffic c authenticating the source, as this will reveal to the CPS both the source and
ontrol system to prevent flooding. Preferably, this should not require authentic destination of traffic. A potential solution is discussed below in <xref target=
ating the source, as this will reveal to the CPS both the source and destination "rate-control" format="default"/>.
of traffic. A potential solution is discussed below in <xref target="rate-contr </t>
ol"/>. </section>
</t> <section anchor="retr" numbered="true" toc="default">
</section> <name>Retrieval</name>
<section anchor="retr" title="Retrieval"> <t>For retrieval of PASSporTs, this architecture assumes that clients wi
<t> ll
For retrieval of PASSporTs, this architecture assumes that clients will contact the CPS through some sort of polling or notification interface to receiv
contact the CPS through some sort of polling or notification interface to recei e all
ve all current PASSporTs for calls destined to a particular telephone number, or block
current PASSporTs for calls destined to a particular telephone number, of numbers.
or block of numbers. </t>
</t> <t>As PASSporTs stored at the CPS are encrypted with a key belonging
<t> to the intended destination, the CPS can safely allow anyone to download PASSpor
As PASSporTs stored at the CPS are encrypted with a key belonging to th Ts
e intended destination, the CPS can safely for a called number without much fear of compromising private information
allow anyone to download PASSporTs for a called number without much fea about calls in progress -- provided that the CPS always returns at least one
r of compromising private information about calls in progress - provided that th encrypted blob in response to a request, even if there was no call in progress.
e CPS always returns at least one encrypted blob in response to a request, even Otherwise, entities could poll the CPS constantly, or eavesdrop on traffic,
if there was no call in progress. Otherwise, entities could poll the CPS constan to learn whether or not calls were in progress. The CPS <bcp14>MUST</bcp14> gene
tly, or eavesdrop on traffic, to learn whether or not calls were in progress. Th rate
e CPS MUST generate at least one unique and plausible encrypted response to all at least one unique and plausible encrypted response to all retrieval requests,
retrieval requests, and these dummy encrypted PASSporTs MUST NOT be repeated for and these dummy encrypted PASSporTs <bcp14>MUST NOT</bcp14> be repeated for
later calls. An encryption scheme needs to be carefully chosen to make messages later calls. An encryption scheme needs to be carefully chosen to make messages
look indistinguishable from random when encrypted, so that information about ca look indistinguishable from random when encrypted, so that information about the
lled party is not discoverable from legitimate encrypted PASSporTs. called party is not discoverable from legitimate encrypted PASSporTs.
</t><t> </t>
Because the entity placing a call may discover multiple keys associated <t>Because the entity placing a call may discover multiple keys
with the called party number, multiple valid PASSporTs may be stored in the CPS associated with the called party number, multiple valid PASSporTs may be
. A particular called party who retrieves PASSporTs from the CPS may have access stored in the CPS. A particular called party who retrieves PASSporTs from
to only one of those keys. Thus, the presence of one or more PASSporTs that the the CPS may have access to only one of those keys. Thus, the presence of
called party cannot decrypt - which would be indistinguishable from the "dummy" one or more PASSporTs that the called party cannot decrypt -- which would
PASSporTS created by the CPS when no calls are in progress - does not entail th be indistinguishable from the "dummy" PASSporTs created by the CPS when
at there is no call in progress. A retriever likely will need to decrypt all PAS no calls are in progress - does not entail that there is no call in progress.
SporTs retrieved from the CPS, and may find only one that is valid. A retriever likely will need to decrypt all PASSporTs retrieved from the CPS,
</t><t> and may find only one that is valid.
In order to prevent the CPS from learning the numbers that a callee controls, ca </t>
llees might also request PASSporTs for numbers that they do not own, that they h <t>In order to prevent the CPS from learning the numbers that a callee
ave no hope of decrypting. Implementations could even allow a callee to request controls, callees might also request PASSporTs for numbers that they do not own,
PASSporTs for a range or prefix of numbers: a trade-off where that callee is wil that they have no hope of decrypting. Implementations could even allow a callee
ling to sift through bulk quantities of undecryptable PASSporTs for the sake of to request PASSporTs for a range or prefix of numbers: a trade-off where that
hiding from the CPS what numbers it controls. callee is willing to sift through bulk quantities of undecryptable PASSporTs
</t><t> for the sake of hiding from the CPS which numbers it controls.
Note that in out-of-band call forwarding cases, special behavior is req </t>
uired to manage the relationship between PASSporTs using the diversion extension <t>Note that in out-of-band call forwarding cases, special behavior is
<xref target="I-D.ietf-stir-passport-divert"/>. The originating authentication required to manage the relationship between PASSporTs using the diversion
service would encrypt the initial PASSporT with the public encryption key of the extension <xref target="I-D.ietf-stir-passport-divert" format="default"/>.
intended destination, but once a call is forwarded, it may go to a destination The originating authentication service encrypts the initial PASSporT with the
that does not possess the corresponding private key and thus could not decrypt t public encryption key of the intended destination, but once a call is forwarded,
he original PASSporT. This requires the retargeting entity to generate encrypted it may go to a destination that does not possess the corresponding private key
PASSporTs that show a secure chain of diversion: a retargeting storer SHOULD us and thus could not decrypt the original PASSporT. This requires the retargeting
e the "div-o" PASSporT type, with its "opt" extension, as specified in <xref ta entity to generate encrypted PASSporTs that show a secure chain of diversion:
rget="I-D.ietf-stir-passport-divert"/> in order to nest the original PASSporT wi a retargeting storer <bcp14>SHOULD</bcp14> use the "div-o" PASSporT type,
thin the encrypted diversion PASSporT. with its "opt" extension, as specified in
</t> <xref target="I-D.ietf-stir-passport-divert" format="default"/>, in order to nes
</section> t
</section> the original PASSporT within the encrypted diversion PASSporT.
</t>
<section anchor="arch" title="Solution Architecture"> </section>
</section>
<section anchor="arch" numbered="true" toc="default">
<name>Solution Architecture</name>
<t>In this section, we discuss a high-level architecture for providing the service <t>In this section, we discuss a high-level architecture for providing the service
described in the previous sections. This discussion is deliberately described in the previous sections. This discussion is deliberately
sketchy, focusing on broad concepts and skipping over details. The sketchy, focusing on broad concepts and skipping over details. The
intent here is merely to provide an overall architecture, not an implementabl e intent here is merely to provide an overall architecture, not an implementabl e
specification. A more concrete example of how this might be specified is give specification. A more concrete example of how this might be specified is give
n in <xref target="web"/>. n in <xref target="web" format="default"/>.
</t> </t>
<section anchor="phone" title="Credentials and Phone Numbers"> <section anchor="phone" numbered="true" toc="default">
<t> <name>Credentials and Phone Numbers</name>
We start from the premise of the <xref target="RFC7340">STIR problem statemen <t>We start from the premise of the
t</xref> that phone numbers can be <xref target="RFC7340" format="default">STIR problem statement</xref> that ph
associated with credentials which can be used to attest one numbers can be
associated with credentials that can be used to attest
ownership of numbers. For purposes of exposition, we will assume ownership of numbers. For purposes of exposition, we will assume
that ownership is associated with the endpoint (e.g., a smartphone) that ownership is associated with the endpoint (e.g., a smartphone),
but it might well be associated with a provider or gateway acting for the but it might well be associated with a provider or gateway acting for the
endpoint instead. It might be the case that multiple entities are endpoint instead. It might be the case that multiple entities are
able to act for a given number, provided that they have the able to act for a given number, provided that they have the
appropriate authority. <xref target="RFC8226"/> describes appropriate authority. <xref target="RFC8226" format="default"/> describes
a credential system suitable for this purpose; the question of how an entity is determined a credential system suitable for this purpose; the question of how an entity is determined
to have control of a given number is out of scope for the current document. to have control of a given number is out of scope for this document.
</t> </t>
</section> </section>
<section anchor="solve" title="Call Flow"> <section anchor="solve" numbered="true" toc="default">
<t> <name>Call Flow</name>
An overview of the basic calling and verification process is show <t>An overview of the basic calling and verification process is shown
n
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.
</t> </t>
<figure> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
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]
]]></artwork> ]]></artwork>
</figure> <t>When Alice wishes to make a call to Bob, she contacts the CPS and
<t>
When Alice wishes to make a call to Bob, she contacts the CPS and
stores an encrypted PASSporT on stores an encrypted PASSporT on
the CPS indexed under Bob's number. The CPS then awaits retrievals for the CPS indexed under Bob's number. The CPS then awaits retrievals for
that number. that number.
</t> </t>
<t> <t>When Alice places the call, Bob's phone would usually ring and displa
When Alice places the call, Bob's phone would usually ring and display y
Alice's number (+1.111.555.1111), which is informed by the existing Alice's number (+1.111.555.1111), which is informed by the existing
PSTN mechanisms for relaying a calling party number (e.g., the CIN field of t PSTN mechanisms for relaying a calling party number (e.g., the
he IAM). Instead, Calling Party's Number (CIN) field of
the Initial Address Message (IAM)). Instead,
Bob's phone transparently contacts the CPS and requests any current Bob's phone transparently contacts the CPS and requests any current
PASSporTs for calls to his number. The CPS responds with any such PASSporTs PASSporTs for calls to his number. The CPS responds with any such PASSporTs
(or dummy PASSporTs if no relevant ones are currently stored). (or dummy PASSporTs if no relevant ones are currently stored).
If such a PASSporT exists, and the verification service in Bob's phone decrypts it using If such a PASSporT exists, and the verification service in Bob's phone decrypts it using
his private key, validates it, then his private key, validates it, then
Bob's phone can present the calling party number Bob's phone can present the calling party number
information as valid. Otherwise, the call is unverifiable. Note information as valid. Otherwise, the call is unverifiable. Note
that this does not necessarily mean that the call is bogus; because that this does not necessarily mean that the call is bogus; because
we expect incremental deployment, many legitimate calls will be we expect incremental deployment, many legitimate calls will be
unverifiable. unverifiable.
</t> </t>
</section> </section>
<section anchor="sec" numbered="true" toc="default">
<name>Security Analysis</name>
<section anchor="sec" title="Security Analysis"> <t>The primary attack we seek to prevent is an attacker convincing the
<t>
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:
</t><t><list style="numbers"><t> </t>
The attacker wishes to impersonate a target when no call from that <ol spacing="normal" type="1">
<li>The attacker wishes to impersonate a target when no call from that
target is in progress. target is in progress.
</t><t> </li>
The attacker wishes to substitute himself for an existing call setup. <li>The attacker wishes to substitute himself for an existing call set
</t></list></t><t> up.
If an attacker can inject fake PASSporTs into the CPS or in the </li>
</ol>
<t>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 As PASSporTs should be
digitally signed by an appropriate authority for the number and verified by t he callee digitally signed by an appropriate authority for the number and verified by t he callee
(see <xref target="phone"/>), this should not arise in ordinary operations. (see <xref target="phone" format="default"/>), this should not arise in ordin
Any attacker who is aware of calls in progress can attempt to mount a race to ary operations.
subtitute themselves Any attacker who is aware of calls in progress can attempt to mount a race to
as described in <xref target="sub"/>. For privacy and robustness reasons, substitute themselves
using <xref target="RFC8446">TLS</xref> on the originating side when storing as described in <xref target="sub" format="default"/>. For privacy and robust
the PASSporT at the CPS is RECOMMENDED. ness reasons,
</t><t> using <xref target="RFC8446" format="default">TLS</xref> on the originating
The entire system depends on the security of the credential side when storing the PASSporT at the CPS is <bcp14>RECOMMENDED</bcp14>.
</t>
<t>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 <xref target="RFC8224"/> S number. However, that is no different from in-band STIR <xref target="RFC8224
TIR. " format="default"/>.
</t><t> </t>
A secondary attack we must also prevent is denial-of-service against the <t>A secondary attack we must also prevent is denial-of-service against
CPS, which requires some form of rate control solution that will not degrade the the CPS, which requires some form of rate control solution that will not degrade
privacy properties of the architecture. the privacy properties of the architecture.
</t> </t>
</section> </section>
<section anchor="sub" title="Substitution Attacks"> <section anchor="sub" numbered="true" toc="default">
<t> <name>Substitution Attacks</name>
All the receipt of the PASSporT from the CPS proves to the called party <t>All that the receipt of the PASSporT from the CPS proves to the calle
d party
is that Alice is trying to call is that Alice is trying to call
Bob (or at least was as of very recently) - it does not prove that Bob (or at least was as of very recently) -- it does not prove that
any particular incoming call is from Alice. Consider the scenario any particular incoming call is from Alice. Consider the scenario
in which we have a service which provides an automatic callback to a in which we have a service that provides an automatic callback to a
user-provided number. In that case, the attacker can try to arrange for a user-provided number. In that case, the attacker can try to arrange for a
false caller-id value, as shown below:</t> false caller-id value, as shown below:</t>
<figure> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
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) -------------------->
Call from CS ------------------------> X Call from CS ------------------------> X
<-- Retrieve PASSporT <-- Retrieve PASSporT
for CS:Bob for CS:Bob
PASSporT for CS:Bob ------------------------> PASSporT for CS:Bob ------------------------>
[Ring phone with callerid = [Ring phone with callerid =
111.555.1111] 111.555.1111]
]]></artwork> ]]></artwork>
</figure><t> <t>In order to mount this attack, the attacker contacts the Callback
In order to mount this attack, the attacker contacts the Callbac
k
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. Because insert an appropriate PASSporT and then initiates a call to Bob. Because
it is a valid CS injecting the PASSporT, none of the security checks it is a valid CS injecting the PASSporT, none of the security checks
mentioned above help. However, the attacker simultaneously initiates mentioned above help. However, the attacker simultaneously initiates
a call to Bob using forged caller-id information corresponding to the a call to Bob using forged caller-id information corresponding to the
CS. If he wins the race with the CS, then Bob's phone will attempt CS. If he wins the race with the CS, then Bob's phone will attempt
to verify the attacker's call (and succeed since they are to verify the attacker's call (and succeed since they are
indistinguishable) and the CS's call will go to busy/voice mail/call indistinguishable), and the CS's call will go to busy/voice mail/call
waiting. waiting.
</t><t> </t>
<t>
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 essential similar means to learn precisely when a call is placed, it is essential
that the connection between the caller and the CPS be encrypted as recommende d above. that the connection between the caller and the CPS be encrypted as recommende d above.
Authentication services could store dummy PASSporTs at the CPS at random inte rvals in order Authentication services could store dummy PASSporTs at the CPS at random inte rvals in order
to make it more difficult for an eavesdropper to use traffic analysis to dete rmine to make it more difficult for an eavesdropper to use traffic analysis to dete rmine
that a call was about to be placed. that a call was about to be placed.
</t><t> </t>
<t>
Note that in a SIP environment, the callee might notice that Note that in a SIP environment, the callee might notice that
there were multiple INVITEs and thus detect this attack, but in some PSTN there were multiple INVITEs and thus detect this attack, but in some PSTN
interworking scenarios, or highly intermediated networks, only one call setup interworking scenarios, or highly intermediated networks, only one call setup
attempt will reach the target. Also note that the success of this substitutio n attempt will reach the target. Also note that the success of this substitutio n
attack depends on the attacker landing their call within the narrow window attack depends on the attacker landing their call within the narrow window
that the PASSporT is retained in the CPS, so that the PASSporT is retained in the CPS, so
shortening that window will reduce the shortening that window will reduce the
opportunity for the attack. Finally, smart endpoints could implement some sor t of opportunity for the attack. Finally, smart endpoints could implement some sor t of
state coordination to ensure that both sides believe the call is in progress, though state coordination to ensure that both sides believe the call is in progress, though
methods of supporting that are outside the scope of this document. methods of supporting that are outside the scope of this document.
</t> </t>
</section> </section>
<section anchor="rate-control" title="Rate Control for CPS Storage"> <section anchor="rate-control" numbered="true" toc="default">
<t> <name>Rate Control for CPS Storage</name>
In order to prevent the flooding of a CPS with bogus PASSporTs, we prop <t>In order to prevent the flooding of a CPS with bogus PASSporTs,
ose the use of "blind signatures" (see <xref target="RFC5636"/>). A sender will we propose the use of "blind signatures" (see <xref target="RFC5636" format="def
initially authenticate to the CPS using its STIR credentials, and acquire a sign ault"/>).
ed token from the CPS that will be presented later when storing a A sender will initially authenticate to the CPS using its STIR credentials
PASSporT. The flow looks as follows: and acquire a signed token from the CPS that will be presented later
</t> when storing a PASSporT. The flow looks as follows:
<figure> </t>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
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)) --->
]]></artwork> ]]></artwork>
</figure> <t>At an initial time when no call is yet in progress, a potential clien
<t> t connects to the CPS, authenticates,
At an initial time when no call is yet in progress, a potential client connects
to the CPS, authenticates,
and sends a blinded version of a freshly generated public key. The and sends a blinded version of a freshly generated public key. The
CPS returns a signed version of that blinded key. The sender can CPS returns a signed version of that blinded key. The sender can
then unblind the key and gets a signature on K_temp from the CPS. then unblind the key and get a signature on K_temp from the CPS.
</t><t> </t>
<t>
Then later, when a client wants to store a PASSporT, it connects Then later, when a client wants to store a PASSporT, it connects
to the CPS anonymously (preferably over a network connection that cannot be corr elated with the token acquisition) and to the CPS anonymously (preferably over a network connection that cannot be corr elated with the token acquisition) and
sends both the signed K_temp and its own signature over the sends both the signed K_temp and its own signature over the
encrypted PASSporT. The CPS verifies both signatures and if they encrypted PASSporT. The CPS verifies both signatures and, if they
verify, stores the encrypted passport (discarding the signatures). verify, stores the encrypted passport (discarding the signatures).
</t><t> </t>
<t>
This design lets the CPS rate limit how many PASSporTs a given 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 pol sender can store just by counting how many times K_temp appears;
icy might reject storage attempts and require acquisition of a new K_temp after perhaps CPS policy might reject storage attempts and require acquisition
storing more than a certain number of PASSporTs indexed under the same destinati of a new K_temp after storing more than a certain number of PASSporTs
on number in a short interval. This does not of course allow the CPS to tell whe indexed under the same destination number in a short interval.
n bogus data is being provisioned by an attacker, This does not, of course, allow the CPS to tell when bogus data
simply the rate at which data is being provisioned. Potentially, feedback mechan is being provisioned by an attacker,
isms could be developed that would allow the called parties to tell the CPS when simply the rate at which data is being provisioned. Potentially,
they are receiving unusual or bogus feedback mechanisms could be developed that would allow the called
parties to tell the CPS when they are receiving unusual or bogus
PASSporTs. PASSporTs.
</t><t> </t>
This architecture also assumes that the CPS will age out PASSporTs. A C <t>
PS SHOULD NOT keep any stored PASSporT for no longer than a value that might be This architecture also assumes that the CPS will age out PASSporTs.
selected for the verification service policy for freshness of the "iat" value as A CPS <bcp14>SHOULD NOT</bcp14> keep any stored PASSporT for longer
described in <xref target="RFC8224"/> (i.e. sixty seconds). Any reduction in th than the recommended freshness
is window makes substitution attacks (see <xref target="sub"/>) harder to mount, policy for the "iat" value as described in
but making the window too small might conceivably age PASSporTs out while a hea <xref target="RFC8224" format="default"/> (i.e., sixty seconds)
vily redirected call is still alerting. unless some local policy for a CPS deployment requires a longer or shorter inter
</t><t> val.
An alternative potential approach to blind signatures would be the use of oblivi Any reduction in this window makes substitution attacks
ous pseudorandom functions (VOPRFs, per <xref target="I-D.privacy-pass"/>), whic (see <xref target="sub" format="default"/>) harder to mount,
h move prove faster. but making the window too small might conceivably age PASSporTs out
</t> while a heavily redirected call is still alerting.
</section> </t>
<t>
An alternative potential approach to blind signatures would be
the use of verifiable oblivious pseudorandom functions (VOPRFs, per
<xref target="I-D.privacy-pass" format="default"/>), which may prove faster.
</t>
</section>
</section> </section>
<section anchor="u8224" numbered="true" toc="default">
<section anchor="u8224" title="Authentication and Verification Service Be <name>Authentication and Verification Service Behavior for Out-of-Band</na
havior for Out-of-Band"> me>
<t> <t>
<xref target="RFC8224"/> defines an authentication service and a verifica <xref target="RFC8224" format="default"/> defines an authentication service and
tion service as functions that act in the context of SIP requests and responses. a verification service as functions that act in the context of SIP requests and
This specification thus provides a more generic description of authentication s responses. This specification thus provides a more generic description of authen
ervice and verification service behavior that might or might not involve any SIP tication service and verification service behavior that might or might not invol
transactions, but depends only on placing a request for communications from ve any SIP transactions, but depends only on placing a request for communication
an originating identity to one or more destination identities. s from
</t> an originating identity to one or more destination identities.
<section anchor="as" title="Authentication Service (AS)"> </t>
<t> <section anchor="as" numbered="true" toc="default">
Out-of-band authentication services perform steps similar to those define <name>Authentication Service (AS)</name>
d in <xref target="RFC8224"/> with some exceptions: <t>
</t><t> Out-of-band authentication services perform steps similar to those defined in <x
Step 1: The authentication service MUST determine whether it is ref target="RFC8224" format="default"/> with some exceptions:
</t>
<t>
Step 1: The authentication service <bcp14>MUST</bcp14> determine whether it is
authoritative for the identity of the originator of the request, that is, th e identity it will populate in the "orig" claim of the PASSporT. authoritative for the identity of the originator of the request, that is, th e identity it will populate in the "orig" claim of the PASSporT.
It can do so only if it possesses the private key of one or more credenti It can do so only if it possesses the private key of one or more credentials tha
als that can be used t can be used
to sign for that identity, be it a domain or a telephone number or some othe to sign for that identity, be it a domain or a telephone number or some othe
r identifier. For example, the authentication service could hold the private key r identifier. For example, the authentication service could hold the private key
associated with a <xref target="RFC8225">STIR certificate</xref>. associated with a <xref target="RFC8225" format="default">STIR certificate</xre
</t><t> f>.
Step 2: The authentication service MUST determine that the originator of </t>
communications can claim the originating identity. This is a policy <t>
decision made by the authentication service that depends on its relations Step 2: The authentication service <bcp14>MUST</bcp14> determine that the
hip to the originator. For an out-of-band application built-in to the originator of communications can claim the originating identity. This is a polic
calling device, for example, this is the same check performed in Step 1: y
does the calling device hold a private key, one corresponding to a STIR certific decision made by the authentication service that depends on its relationship to
ate, the originator. For an out-of-band application built into the
that can sign for the originating identity? calling device, for example, this is the same check performed in Step 1: does th
</t><t> e
Step 3: The authentication service MUST acquire the public encryption key calling device hold a private key, one corresponding to a STIR certificate,
of the destination, which will be used to encrypt the PASSporT (see <xref targe that can sign for the originating identity?
t="lookup"/>). It MUST also discover (see <xref target="cps"/>) </t>
the CPS associated with the destination. The authentication service <t anchor="as-step3">
may already have the encryption key and destination CPS cached, or may ne Step 3: The authentication service <bcp14>MUST</bcp14> acquire the public encryp
ed to query a service to acquire the key. Note that per <xref target="rate-contr tion key
ol"/> the authentication service may also need to acquire a token for PASSporT s of the destination, which will be used to encrypt the PASSporT (see <xref target
torage from the CPS upon CPS discovery. It is anticipated that the discovery mec ="lookup" format="default"/>).
hanism (see <xref target="cps"/>) used to find the appropriate It <bcp14>MUST</bcp14> also discover (see <xref target="cps" format="default"/>)
CPS will also find the proper key server for the public key of the destin the CPS associated with the destination. The authentication service
ation. In some cases, a destination may have multiple public encryption keys ass may already have the encryption key and destination CPS cached, or may need
ociated with it. In that case, the authentication service MUST collect all of th to query a service to acquire the key. Note that per <xref target="rate-control"
ose keys. format="default"/>,
</t><t> the authentication service may also need to acquire a token for PASSporT
Step 4: The authentication service MUST create the PASSporT object. This storage from the CPS upon CPS discovery. It is anticipated that the discovery me
includes acquiring the system time to populate the "iat" claim, and populating t chanism
he "orig" and "dest" claims as (see <xref target="cps" format="default"/>) used to find the appropriate
described in <xref target="RFC8225"/>. The authentication service MUST th CPS will also find the proper key server for the public key of the destination.
en encrypt the PASSporT. If in Step 3 the authentication service discovered mult In some cases, a destination may have multiple public encryption keys associated
iple public keys for the destination, it with it.
MUST create one encrypted copy for each public key it discovered. In that case, the authentication service <bcp14>MUST</bcp14> collect all of thos
</t><t> e keys.
Finally, the authentication service stores the encrypted PASSporT(s) at t </t>
he CPS discovered in Step 3. Only after that is completed should any call be ini <t>
tiated. Note that a call might be initiated over SIP, and the authentication Step 4: The authentication service <bcp14>MUST</bcp14> create the PASSporT objec
service would place the same PASSporT in the Identity header field value t. This includes acquiring the system time to populate the "iat" claim, and popu
of the SIP request - though SIP would carry a cleartext version rather than an e lating the "orig" and "dest" claims as
ncrypted version sent to the CPS. In that case, out-of-band would serve as a fal described in <xref target="RFC8225" format="default"/>. The authentication servi
lback mechanism in case the request was not conveyed over SIP end-to-end. Also, ce <bcp14>MUST</bcp14> then encrypt the PASSporT. If in Step 3 the authenticatio
note that the authentication service MAY n service discovered multiple public keys for the destination, it
use a compact form of the PASSporT for a SIP request, whereas the version <bcp14>MUST</bcp14> create one encrypted copy for each public key it disc
stored at the CPS MUST always be a full form PASSporT. overed.
</t> </t>
</section> <t>
<section anchor="vs" title="Verification Service (VS)"> Finally, the authentication service stores the encrypted PASSporT(s) at the CPS
<t> discovered in Step 3. Only after that is completed should any call be initiated.
When a call arrives, an out-of-band verification service performs steps s Note that a call might be initiated over SIP, and the authentication
imilar to those defined in <xref target="RFC8224"/> with some exceptions: service would place the same PASSporT in the Identity header field value of the
</t><t> SIP request --
Step 1: The verification service contacts the CPS and requests all curren though SIP would carry a cleartext version rather than an encrypted version
t PASSporTs for its destination number; or alternatively it may receive PASSporT sent to the CPS. In that case, out-of-band would serve as a fallback mechanism
s through a push interface from the CPS in some deployments. The verification se if the request was not conveyed over SIP end-to-end. Also, note that the
rvice MUST then decrypt all PASSporTs using its private key. Some PASSporTs may authentication service <bcp14>MAY</bcp14> use a compact form of the PASSporT
not be decryptable for any number of reasons: they may be intended for a differe for a SIP request, whereas the version stored at the CPS <bcp14>MUST</bcp14>
nt verification service, or they may be "dummy" values inserted by the CPS for p always be a full-form PASSporT.
rivacy purposes. The next few steps will narrow down the set of PASSporTs that t </t>
he verification service will examine from that initial decryptable set. </section>
</t><t> <section anchor="vs" numbered="true" toc="default">
Step 2: The verification service MUST determine if any "ppt" extensions i <name>Verification Service (VS)</name>
n the PASSporTs are unsupported. It takes only the set of supported PASSporTs an <t>
d applies the next step to them. When a call arrives, an out-of-band verification service performs steps similar
</t><t> to those defined in <xref target="RFC8224" format="default"/> with some exceptio
Step 3: The verification service MUST determine if there is an overlap be ns:
tween the calling party number presented in call signaling and the "orig" field </t>
of any decrypted PASSporTs. It takes the set of matching PASSporTs and applies t <t anchor="vs-step1">
he next step to them. Step 1: The verification service contacts the CPS and requests all current PASSp
</t><t> orTs for its destination number; or alternatively it may receive PASSporTs throu
Step 4: The verification service MUST determine if the credentials that s gh a push interface from the CPS in some deployments. The verification service <
igned each PASSporT are valid, and if the verification service trusts the CA tha bcp14>MUST</bcp14> then decrypt all PASSporTs using its private key. Some PASSpo
t issued the credentials. It takes the set rTs may not be decryptable for any number of reasons: they may be intended for a
of trusted PASSporTs to the next step. different verification service, or they may be "dummy" values inserted by the C
</t><t> PS for privacy purposes. The next few steps will narrow down the set of PASSporT
Step 5: The verification service MUST check the freshness of the "iat" cl s that the verification service will examine from that initial decryptable set.
aim of each PASSporT. The exact interval of time that determines freshness is le </t>
ft to local policy. It takes the set of fresh PASSporTs to the next step. <t>
</t><t> Step 2: The verification service <bcp14>MUST</bcp14> determine if any "ppt" exte
Step 6: The verification service MUST check the validity of the signature nsions in the PASSporTs are unsupported. It takes only the set of supported PASS
over each PASSporT, as described in <xref target="RFC8225"/>. porTs and applies the next step to them.
</t><t> </t>
Finally, the verification service will end up with one or more valid PASS <t>
porTs corresponding to the call it has received. In keeping with baseline STIR, Step 3: The verification service <bcp14>MUST</bcp14> determine if there is an ov
this document does not dictate any particular treatment of calls that have valid erlap between the calling party number presented in call signaling and the "orig
PASSporTs associated with them; the handling of the call " field of any decrypted PASSporTs. It takes the set of matching PASSporTs and a
pplies the next step to them.
</t>
<t>
Step 4: The verification service <bcp14>MUST</bcp14> determine if the credential
s that signed each PASSporT are valid, and if the verification service trusts th
e CA that issued the credentials. It takes the set
of trusted PASSporTs to the next step.
</t>
<t>
Step 5: The verification service <bcp14>MUST</bcp14> check the freshness of the
"iat" claim of each PASSporT. The exact interval of time that determines freshne
ss is left to local policy. It takes the set of fresh PASSporTs to the next step
.
</t>
<t>
Step 6: The verification service <bcp14>MUST</bcp14> check the validity of the s
ignature over each PASSporT, as described in <xref target="RFC8225" format="defa
ult"/>.
</t>
<t>
Finally, the verification service will end up with one or more valid PASSporTs c
orresponding to the call it has received. In keeping with baseline STIR, this do
cument does not dictate any particular treatment of calls that have valid PASSpo
rTs associated with them; the handling of the call
after the verification process depends on how the verification after the verification process depends on how the verification
service is implemented and on local policy. However, it is anticipated that l ocal policies could involve service is implemented and on local policy. However, it is anticipated that l ocal policies could involve
making different forwarding decisions in intermediary making different forwarding decisions in intermediary
implementations, or changing how the user is alerted or how identity implementations, or changing how the user is alerted or how identity
is rendered in UA implementations. is rendered in user agent implementations.
</t> </t>
</section> </section>
<section anchor="hybrid" title="Gateway Placement Services"> <section anchor="hybrid" numbered="true" toc="default">
<t> <name>Gateway Placement Services</name>
The STIR out-of-band mechanism also supports the presence of gateway plac <t>
ement services, which do not create PASSporTs themselves, but instead take PASSp The STIR out-of-band mechanism also supports the presence of gateway placement s
orTs out of signaling protocols and store them at a CPS before gatewaying to a p ervices, which do not create PASSporTs themselves, but instead take PASSporTs ou
rotocol that cannot carry PASSporTs itself. For example, a SIP gateway that send t of signaling protocols and store them at a CPS before gatewaying to a protocol
s calls to the PSTN could receive a call with an Identity header field, extract that cannot carry PASSporTs itself. For example, a SIP gateway that sends calls
a PASSporT from the Identity header field, and store that PASSporT at a CPS. to the PSTN could receive a call with an Identity header field, extract a PASSp
</t><t> orT from the Identity header field, and store that PASSporT at a CPS.
To place a PASSporT at a CPS, a gateway MUST perform Step 3 of <xref targ </t>
et="as"/> above: that is, it must discover the CPS and public key associated wit <t>
h the destination of the call, and may need to acquire a PASSporT storage token To place a PASSporT at a CPS, a gateway <bcp14>MUST</bcp14> perform
(see <xref target="stor"/>). Per Step 3 of <xref target="as"/> this may entail d <xref target="as-step3" format="none">Step 3</xref> of <xref target="as" format=
iscovering several keys. The gateway then collects the in-band PASSporT(s) from "default"/> above:
the in-band signaling, encrypts the PASSporT(s), and stores them at the CPS. that is, it must discover the CPS and public key associated with the
</t><t> destination of the call, and may need to acquire a PASSporT storage token
A similar service could be performed by a gateway that retrieves PASSporT (see <xref target="stor" format="default"/>). Per <xref target="as-step3" format
s from a CPS and inserts them into signaling protocols that support carrying PAS ="none">Step 3</xref>
SporTS in-band. This behavior may be defined by future specifications. of <xref target="as" format="default"/>, this may entail discovering several key
</t> s.
</section> The gateway then collects the in-band PASSporT(s) from the in-band signaling,
</section> encrypts the PASSporT(s), and stores them at the CPS.
</t>
<section anchor="web" title="Example HTTPS Interface to the CPS"> <t>
<t> A similar service could be performed by a gateway that retrieves PASSporTs from
As a rough example, we show a Call Placement Service implementation here a CPS and inserts them into signaling protocols that support carrying PASSporTs
which uses a REST API to store and retrieve objects at the CPS. The calling part in-band. This behavior may be defined by future specifications.
y stores the PASSporT at the CPS prior to initiating the call; the </t>
PASSporT is stored at a location at the CPS that corresponds to the calle </section>
d number. Note that it is possible for multiple parties to be calling a number a </section>
t the same time, and that for called <section anchor="web" numbered="true" toc="default">
numbers such as large call centers, many PASSporTs could legitimately be <name>Example HTTPS Interface to the CPS</name>
stored simultaneously, and it might prove difficult to correlate these with inco <t>
ming calls. As a rough example, we show a CPS implementation here that uses a
</t> Representational State Transfer (REST) API <xref target="REST"/> to store and re
<t> trieve objects at the CPS.
Assume that an authentication service has created the following PASSporT The calling party stores the PASSporT at the CPS prior to initiating the call; t
for a call to the telephone number 2.222.555.2222 (note that these are dummy val he
ues): PASSporT is stored at a location at the CPS that corresponds to the called numbe
</t> r.
<figure> Note that it is possible for multiple parties to be calling a number at the same
<artwork><![CDATA[ time, and that for called
numbers such as large call centers, many PASSporTs could legitimately be stored
simultaneously, and it might prove difficult to correlate these with incoming ca
lls.
</t>
<t>
Assume that an authentication service has created the following PASSporT for a c
all to the telephone number 2.222.555.2222 (note that these are dummy values):
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9 eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9
jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJkZXN0Ijp7InRuIjpbI jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJkZXN0Ijp7InRuIjpbI
jIyMjI1NTUyMjIyIl19LCJpYXQiOiIxNTgzMjUxODEwIiwib3JpZyI6eyJ0biI6 jIyMjI1NTUyMjIyIl19LCJpYXQiOiIxNTgzMjUxODEwIiwib3JpZyI6eyJ0biI6
IjExMTE1NTUxMTExIn19.pnij4IlLHoR4vxID0u3CT1e9Hq4xLngZUTv45Vbxmd IjExMTE1NTUxMTExIn19.pnij4IlLHoR4vxID0u3CT1e9Hq4xLngZUTv45Vbxmd
3IVyZug4KOSa378yfP4x6twY0KTdiDypsereS438ZHaQ 3IVyZug4KOSa378yfP4x6twY0KTdiDypsereS438ZHaQ
]]></artwork> ]]></artwork>
</figure> <t>
<t> Through some discovery mechanism (see <xref target="cps" format="default"/>), th
Through some discovery mechanism (see <xref target="cps"/>), the authenti e authentication service discovers the network location of a web service that ac
cation service discovers the network location of a web service that acts as the ts as the CPS for 2.222.555.2222. Through the same mechanism, we will say that i
CPS for 2.222.555.2222. Through the same mechanism, we will say that it has also t has also discovered one public encryption key for that destination. It uses th
discovered one public encryption key for that destination. It uses that encrypt at encryption key to encrypt the PASSporT, resulting in the encrypted PASSporT:
ion key to encrypt the PASSporT, resulting in the encrypted PASSporT: </t>
</t> <artwork name="" type="" align="left" alt=""><![CDATA[
<figure>
<artwork><![CDATA[
rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w
MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm
nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV
wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1 wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1
IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j
]]></artwork> ]]></artwork>
</figure> <t>
<t> Having concluded the numbered steps in <xref target="as" format="default"/>, inc
Having concluded the numbered steps in <xref target="as"/>, including ac luding acquiring any token (per <xref target="stor" format="default"/>) needed t
quiring any token (per <xref target="stor"/>) needed to store the PASSporT at th o store the PASSporT at the CPS, the authentication service then stores the encr
e CPS, the authentication service then stores the encrypted PASSporT: ypted PASSporT:
</t> </t>
<figure> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
POST /cps/2.222.555.2222/ppts HTTP/1.1 POST /cps/2.222.555.2222/ppts HTTP/1.1
Host: cps.example.com Host: cps.example.com
Content-Type: application/passport Content-Type: application/passport
rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w
MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm
nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV
wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1 wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1
IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j
]]></artwork> ]]></artwork>
</figure> <t>
<t> The web service assigns a new location for this encrypted PASSporT in the collec
The web service assigns a new location for this encrypted PASSporT in the tion, returning a 201 OK with the location of /cps/2.222.222.2222/ppts/ppt1.
collection, returning a 201 OK with the location of /cps/2.222.222.2222/ppts/pp Now the authentication service can place the call, which may be signaled by vari
t1. ous protocols. Once the call arrives at the terminating side, a verification ser
Now the authentication service can place the call, which may be signaled vice
by various protocols. Once the call arrives at the terminating side, a verificat contacts its CPS to ask for the set of incoming calls for its telephone number (
ion service 2.222.222.2222).
contacts its CPS to ask for the set of incoming calls for its telephone n </t>
umber (2.222.222.2222). <artwork name="" type="" align="left" alt=""><![CDATA[
</t>
<figure>
<artwork><![CDATA[
GET /cps/2.222.555.2222/ppts GET /cps/2.222.555.2222/ppts
Host: cps.example.com Host: cps.example.com
]]></artwork> ]]></artwork>
</figure> <t>
<t> This returns to the verification service a list of the PASSporTs currently in t
This returns to the verification service a list of the PASSporTs current he collection, which currently consists of only /cps/2.222.222.2222/ppts/ppt1. T
ly in the collection, which currently consists of only /cps/2.222.222.2222/ppts/ he verification
ppt1. The verification service then sends a new GET for /cps/2.222.555.2222/ppts/ppt1/ which yields:
service then sends a new GET for /cps/2.222.555.2222/ppts/ppt1/ which yi </t>
elds: <artwork name="" type="" align="left" alt=""><![CDATA[
</t>
<figure>
<artwork><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/passport Content-Type: application/passport
Link: <https://cps.example.com/cps/2.222.555.2222/ppts> Link: <https://cps.example.com/cps/2.222.555.2222/ppts>
rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w
MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm
nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV
wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1 wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1
IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j
]]></artwork> ]]></artwork>
</figure> <t>
<t> That concludes <xref target="vs-step1" format="none">Step 1</xref> of <xref tar
That concludes Step 1 of <xref target="vs"/>; the verification service t get="vs" format="default"/>; the verification service then goes on to the next s
hen goes on to the next step, processing that PASSporT through its various check tep, processing that PASSporT through its various checks. A complete protocol de
s. A complete protocol description for CPS interactions is left to future work. scription for CPS interactions is left to future work.
</t> </t>
</section> </section>
<section anchor="cps" numbered="true" toc="default">
<section anchor="cps" title="CPS Discovery"> <name>CPS Discovery</name>
<t> <t>
In order for the two ends of the out-of-band dataflow to coordinate, they In order for the two ends of the out-of-band dataflow to coordinate, they must a
must agree on a way to discover a CPS and retrieve PASSporT objects from it gree on a way to discover a CPS and retrieve PASSporT objects from it
based solely on the rendezvous information available: the calling party n based solely on the rendezvous information available: the calling party number a
umber and the called number. Because the storage of PASSporTs in this architectu nd the called number. Because the storage of PASSporTs in this architecture is i
re is indexed ndexed
by the called party number, it makes sense to discover a CPS based on the by the called party number, it makes sense to discover a CPS based on the called
called party number as well. party number as well.
There are a number of potential service discovery mechanisms that could b There are a number of potential service discovery mechanisms that could be used
e used for for
this purpose. The means of service discovery may vary by use case. this purpose. The means of service discovery may vary by use case.
</t><t> </t>
Although the discussion above is written largely in terms of a single CP <t>
S, having a significant fraction of all telephone calls result in storing and re Although the discussion above is written largely in terms of a single CPS, havi
trieving PASSporTs at a single monolithic CPS ng a significant fraction of all telephone calls result in storing and retrievin
g PASSporTs at a single monolithic CPS
has obvious scaling problems, and would as well allow the CPS to has obvious scaling problems, and would as well allow the CPS to
gather metadata about a very wide set of callers and callees. These issues can be alleviated by operational models with a gather metadata about a very wide set of callers and callees. These issues can be alleviated by operational models with a
federated CPS; any service discovery mechanism for out-of-band STIR should en federated CPS; any service discovery mechanism for out-of-band STIR
able federation of the CPS function. Likely models include ones should enable federation of the CPS function. Likely models include ones
where a carrier operates one or more CPS instances on behalf of its customers where a carrier operates one or more CPS instances on behalf of its customers
, enterprises run a CPS instance on behalf of their PBX users, or where third-pa ,
rty service providers offer a CPS as a cloud service. an enterprise runs a CPS instance on behalf of its PBX users, or a third-party s
</t><t> ervice provider
offers a CPS as a cloud service.
</t>
<t>
Some service discovery possibilities under consideration include the followin g: Some service discovery possibilities under consideration include the followin g:
<list><t> </t>
For some deployments in closed (e.g. intranetwork) environments, the CPS loca <ul empty="true" spacing="normal">
tion can simply <li>
For some deployments in closed (e.g., intra-network) environments, the CPS lo
cation can simply
be provisioned in implementations, obviating the need for a discovery protoco l. be provisioned in implementations, obviating the need for a discovery protoco l.
</t><t> </li>
If a credential lookup service is already available (see <xref target="lookup <li>
"/>), If a credential lookup service is already available (see <xref target="lookup
the CPS location can also be recorded in the callee's credentials; an extensi " format="default"/>),
on to <xref target="RFC8226"/> could for example provide a link to the location the CPS location can also be recorded in the callee's credentials;
of the CPS an extension to <xref target="RFC8226" format="default"/> could, for example,
provide a link to the location of the CPS
where PASSporTs should be stored for a destination. where PASSporTs should be stored for a destination.
</t><t> </li>
There exist a number of common directory systems that might be used to tr <li>
anslate telephone numbers into the URIs of a CPS. <xref target="RFC6116">ENUM</x There exist a number of common directory systems that might be used to translate
ref> is commonly implemented, telephone numbers into the URIs of a CPS.
though no "golden root" central ENUM administration exists that could be <xref target="RFC6116" format="default">ENUM</xref> is commonly implemented,
easily reused today to help the endpoints discover a common CPS. Other protocols though no "golden root" central ENUM administration exists that could be easily
associated with queries for reused today to help the endpoints discover a common CPS. Other protocols associ
telephone numbers, such as the <xref target="I-D.ietf-modern-teri">TeRI</ ated
xref> protocol, could also serve for this application. with queries for telephone numbers, such as the
</t><t> <xref target="I-D.ietf-modern-teri" format="default">Telephone-Related Informati
Another possibility is to use a single distributed service for this funct on (TeRI) protocol</xref>,
ion. <xref target="I-D.jennings-vipr-overview">VIPR</xref> proposed a could also serve for this application.
<xref target="RFC6940">RELOAD</xref> usage for telephone numbers to help </li>
direct calls to enterprises on the Internet. It would be possible to describe a <li>
similar RELOAD usage Another possibility is to use a single distributed service for this function.
to identify the CPS where calls for a particular telephone number should <xref target="I-D.jennings-vipr-overview" format="default">Verification Involvin
be stored. One advantage that the STIR architecture has over VIPR is that it ass g PSTN Reachability (VIPR)</xref> proposed a
umes a credential system <xref target="RFC6940" format="default">REsource LOcation And Discovery (RELOAD)
that proves authority over telephone numbers; those credentials could be </xref> usage for telephone numbers to help direct calls to enterprises on the I
used to determine whether or not a CPS could legitimately claim to be the proper nternet. It would be possible to describe a similar RELOAD usage
store for a given telephone to identify the CPS where calls for a particular telephone number should be stor
number. ed.
</t></list></t><t> One advantage that the STIR architecture has over VIPR is that it assumes a cred
This document does not prescribe any single way to do service discovery f ential system
or a CPS; it is envisioned that initial deployments will provision the location that proves authority over telephone numbers; those credentials could be used to
of the CPS at the Authentication Service and Verification Service. determine
</t> whether or not a CPS could legitimately claim to be the proper store for a given
</section> telephone
number.
<section anchor="lookup" title="Encryption Key Lookup"> </li>
</ul>
<t> <t>
In order to encrypt a PASSporT (see <xref target="stor"/>), the caller needs This document does not prescribe any single way to do service discovery for a CP
access to the callee's S;
public encryption key. Note that because STIR uses ECDSA for signing PASSporT it is envisioned that initial deployments will provision the location of the CPS
s, the public key used to at the authentication service and verification service.
verify PASSporTs is not suitable for this function, and thus the encryption k </t>
ey must be discovered separately. This requires some sort </section>
<section anchor="lookup" numbered="true" toc="default">
<name>Encryption Key Lookup</name>
<t>
In order to encrypt a PASSporT (see <xref target="stor" format="default"/>),
the caller needs access to the callee's
public encryption key. Note that because STIR uses the Elliptic Curve Digital
Signature Algorithm (ECDSA)
for signing PASSporTs, the public key used to
verify PASSporTs is not suitable for this function, and thus the encryption k
ey
must be discovered separately. This requires some sort
of directory/lookup system. of directory/lookup system.
</t><t> </t>
<t>
Some initial STIR deployments have fielded certificate repositories so that v erification services Some initial STIR deployments have fielded certificate repositories so that v erification services
can acquire the signing credentials for PASSporTs, which are linked throu can acquire the signing credentials for PASSporTs, which are linked through a UR
gh a URI in the "x5u" element of the PASSporT. I in the "x5u" element of the PASSporT.
These certificate repositories could clearly be repurposed for allowing a These certificate repositories could clearly be repurposed for allowing authenti
uthentication services to download cation services to download
the public encryption key for the called party - provided they can be dis the public encryption key for the called party -- provided they can be discovere
covered by calling parties. d by calling parties.
This document does not specify any This document does not specify any
particular discovery scheme, but instead offers some general guidance about p otential approaches. particular discovery scheme, but instead offers some general guidance about p otential approaches.
</t><t> </t>
It is a desirable property that the public encryption key for a given party b <t>
e linked to their STIR credential. An <xref target="RFC7748">ECDH</xref> public- It is a desirable property that the public encryption key for a given party
private key pair might be generated for a <xref target="I-D.ietf-tls-subcerts">s be linked to their STIR credential. An <xref target="RFC7748" format="default">E
ubcert</xref> of the STIR credential. That subcert could be looked up along with lliptic Curve Diffie-Hellman (ECDH)</xref>
the STIR credential of the called party. Further details of this subcert, and t public-private key pair might be generated for a
he exact lookup mechanism involved, are deferred for future protocol work. <xref target="I-D.ietf-tls-subcerts" format="default">subcert</xref> of the STIR
</t><t> credential.
That subcert could be looked up along with the STIR credential of the called par
ty.
Further details of this subcert, and the exact lookup mechanism involved, are de
ferred for future protocol work.
</t>
<t>
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 callee each access in real time to download the other's
keys, then this represents a real privacy risk, as the central keys, then this represents a real privacy risk, as the central
key database learns about each call. A number of mechanisms are key database learns about each call. A number of mechanisms are
potentially available to mitigate this: potentially available to mitigate this:
</t><t><list><t> </t>
Have endpoints pre-fetch keys for potential counterparties <ul empty="true" spacing="normal">
<li>
Have endpoints pre-fetch keys for potential counterparties
(e.g., their address book or the entire database). (e.g., their address book or the entire database).
</t><t> </li>
Have caching servers in the user's network that proxy their <li>
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.
</t></list></t><t> </li>
Clearly, there is a privacy/timeliness tradeoff in that getting </ul>
<t>
Clearly, there is a privacy/timeliness trade-off in that getting
up-to-date knowledge about credential validity requires up-to-date knowledge about credential validity requires
contacting the credential directory in real-time (e.g., via <xref target="RFC contacting the credential directory in real-time (e.g., via the
2560">OCSP</xref>). <xref target="RFC6960" format="default">Online Certificate Status Protocol (O
CSP)</xref>).
This is somewhat mitigated for the caller's credentials in that he This is somewhat mitigated for the caller's credentials in that he
can get short-term credentials right before placing a call which only can get short-term credentials right before placing a call which only
reveals his calling rate, but not who he is calling. Alternately, reveals his calling rate, but not who he is calling. Alternately,
the CPS can verify the caller's credentials via OCSP, though of the CPS can verify the caller's credentials via OCSP, though of
course this requires the callee to trust the CPS's verification. course this requires the callee to trust the CPS's verification.
This approach does not work as well for the callee's credentials, but This approach does not work as well for the callee's credentials, but
the risk there is more modest since an attacker would need to both the risk there is more modest since an attacker would need to both
have the callee's credentials and regularly poll the database for have the callee's credentials and regularly poll the database for
every potential caller. every potential caller.
</t><t> </t>
We consider the exact best point in the tradeoff space to be an open <t>
We consider the exact best point in the trade-off space to be an open
issue. issue.
</t> </t>
</section>
<section anchor="Acknowledgments" title="Acknowledgments">
<t>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, Mar
y Barnes, Ben Campbell, Ted Huang,
Jonathan Rosenberg and Robert Sparks for helpful suggestions.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t>This memo includes no request to IANA.</t> <t>This document has no IANA actions.</t>
</section> </section>
<section anchor="priv" numbered="true" toc="default">
<section anchor="priv" title="Privacy Considerations"> <name>Privacy Considerations</name>
<t> <t>
Delivering PASSporTs out-of-band offers a different set of privacy propertie Delivering PASSporTs out-of-band offers a different set of privacy propertie
s than traditional in-band STIR. In-band operations convey s
PASSporTs as headers in SIP messages in cleartext, which any forwarding inte than traditional in-band STIR. In-band operations convey
rmediaries can potentially inspect. By contrast, out-of-band PASSporTs as headers in SIP messages in cleartext, which any
STIR stores these PASSporTs at a service after encrypting them as described forwarding intermediaries can potentially inspect. By contrast, out-of-band
in <xref target="authz"/>, effectively creating a path STIR stores these PASSporTs at a service after encrypting them
between the authentication and verification service in which the CPS is the as described in <xref target="authz" format="default"/>, effectively creating a
sole intermediary, but the CPS cannot read the PASSporTs. path
between the authentication and verification service in which the CPS
is the sole intermediary, but the CPS cannot read the PASSporTs.
Potentially, out-of-band PASSporT delivery could thus improve on the privacy story of STIR. Potentially, out-of-band PASSporT delivery could thus improve on the privacy story of STIR.
</t><t> </t>
The principle actors in the operation of out-of-band are the AS, VS, and CPS <t>
. The AS and VS functions differ from baseline <xref target="RFC8224"/> behavior The principle actors in the operation of out-of-band are the
, in that they interact with an CPS over a non-SIP interface, of which the REST AS, VS, and CPS. The
interface in <xref target="web"/> serves as an example. Some out-of-band deploym AS and VS functions differ from baseline behavior <xref target="RFC8224" format=
ents may also require a discovery service for the CPS itself (<xref target="cps" "default"/>,
/>) and/or encryption keys (<xref target="lookup"/>). Even with encrypted PASSpo in that they interact with a CPS over a non-SIP interface,
rTs, the network interactions by which the AS and VS interact with the CPS, and of which the REST interface in <xref target="web" format="default"/> serves as a
to a lesser extent any discovery services, thus create potential opportunities f n example.
or data leakage about calling and called parties. Some out-of-band deployments may also require a discovery service for the
</t><t> CPS itself (<xref target="cps" format="default"/>) and/or encryption keys
The process of storing and retrieving PASSporTs at a CPS can itself reveal i (<xref target="lookup" format="default"/>). Even with encrypted PASSporTs,
nformation about calls being placed. The mechanism takes the network interactions by which the AS and VS interact with the CPS, and
care not to require that the AS authenticate itself to the CPS, relying inst to a lesser extent any discovery services, thus create potential opportunities
ead on a blind signature mechanism for flood control prevention. for data leakage about calling and called parties.
<xref target="sub"/> </t>
discusses the practice of storing "dummy" PASSporTs at random intervals to t <t>
hwart traffic analysis, and as <xref target="vs"/> notes, a CPS is required to The process of storing and retrieving PASSporTs at a CPS can itself
return a dummy PASSporT even if there is no PASSporT indexed for that callin reveal information about calls being placed. The mechanism takes
g number, which similarly enables the retrieval side to care not to require that the AS authenticate itself to the CPS,
randomly request PASSporTs when there are no calls in progress. These measur relying instead on a blind signature mechanism for flood control prevention.
es can help to mitigiate information disclosure in the system. In implementation <xref target="sub" format="default"/>
s that require service discovery (see <xref target="cps"/>), perhaps through key discusses the practice of storing "dummy" PASSporTs at random intervals
discovery (<xref target="lookup"/>), similar measures could be used to make sur to thwart traffic analysis, and as <xref target="vs" format="default"/> notes, a
e that service discovery does not itself disclose information about calls. CPS is required to
</t><t> return a dummy PASSporT even if there is no PASSporT indexed for
Ultimately, this document only provides a framework for future implementatio that calling number, which similarly enables the retrieval side to
n of out-of-band systems, and the privacy properties of a given implementation w randomly request PASSporTs when there are no calls in progress.
ill depend on architectural assumptions made in those environments. More closed These measures can help to mitigate information disclosure in the system.
systems for intranet operations may adopt a weaker security posture but otherwis In implementations that require service discovery
e mitigate the risks of information disclosure, where more open environment will (see <xref target="cps" format="default"/>), perhaps through key discovery
require careful implementation of the practices described here. (<xref target="lookup" format="default"/>), similar measures could be used
</t><t> to make sure that service discovery does not itself disclose information about c
For general privacy risks associated with the operations of STIR, also see t alls.
he Privacy Considerations of <xref target="RFC8224"/>. </t>
</t> <t>
</section> Ultimately, this document only provides a framework for future implementatio
n
<section anchor="Security" title="Security Considerations"> of out-of-band systems, and the privacy properties of a given implementation wil
l
depend on architectural assumptions made in those environments. More closed
systems for intranet operations may adopt a weaker security posture but
otherwise mitigate the risks of information disclosure, whereas more open enviro
nments
will require careful implementation of the practices described here.
</t>
<t>
For general privacy risks associated with the operations of STIR,
also see the privacy considerations covered in <xref target="RFC8224" section="1
1" sectionFormat="of" format="default"/>.
</t>
</section>
<section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>This entire document is about security, but the detailed security <t>This entire document is about security, but the detailed security
properties will vary depending on how the framework is applied and deployed. General guidance for dealing properties will vary depending on how the framework is applied and deployed. General guidance for dealing
with the most obvious security challenges posed by this framework is given with the most obvious security challenges posed by this framework is given
in <xref target="sec"/> and <xref target="sub"/>, along proposed solutions for in
problems like denial-of-service attacks or traffic analysis against the CPS.</t> Sections <xref target="sec" format="counter"/> and <xref target="sub" format="co
<t>Although there are considerable security challenges associated with wid unter"/>,
espread deployment of a public CPS, those must be weighed against the potential along proposed solutions for problems like denial-of-service attacks or traffic
usefulness of a service that delivers a STIR assurance without requiring the pas analysis against the CPS.</t>
sage of end-to-end SIP. Ultimately, the security properties of this mechanism ar <t>Although there are considerable security challenges associated with
e at least comparable to in-band widespread deployment of a public CPS, those must be weighed against the
STIR: the substitution attack documented in <xref target="sub"/> could potential usefulness of a service that delivers a STIR assurance without
be implemented by any in-band SIP intermediary or eavesdropper who happened to s requiring the passage of end-to-end SIP. Ultimately, the security properties
ee the PASSporT in transit, say, and launch its own call with a copy of that PAS of this mechanism are at least comparable to in-band
SporT to race against the original to the destination. STIR: the substitution attack documented in <xref target="sub" format="default
"/>
could be implemented by any in-band SIP intermediary or eavesdropper who
happened to see the PASSporT in transit, say, and launched its own call with a
copy of that PASSporT to race against the original to the destination.
</t> </t>
</section> </section>
</middle> </middle>
<!-- *****BACK MATTER ***** -->
<back> <back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation librarie <displayreference target="I-D.ietf-stir-passport-divert" to="PASSPORT-DIVERT"/>
s: <displayreference target="I-D.ietf-modern-teri" to="MODERN-TERI"/>
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here ( <displayreference target="I-D.ietf-tls-subcerts" to="TLS-SUBCERTS"/>
as shown) <displayreference target="I-D.privacy-pass" to="PRIVACY-PASS"/>
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml <displayreference target="I-D.jennings-vipr-overview" to="VIPR-OVERVIEW"/>
"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.x
ml")
Both are cited textually in the same manner: by using xref elements. <references>
If you use the PI option, xml2rfc will, by default, try to find included fil <name>Informative References</name>
es in the same <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
directory as the including file. You can also define the XML_LIBRARY environ ce.RFC.2119.xml"/>
ment variable <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
with a value containing a set of directories to search. These can be either ce.RFC.6960.xml"/>
in the local <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
filing system or remote ones accessed by http (http://domain/dir/... ).--> ce.RFC.5636.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7340.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7258.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.3261.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6116.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6940.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7748.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8224.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8225.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8226.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8446.xml"/>
<references title="Informative References"> <!-- [I-D.draft-ietf-stir-passport-divert] IANA state as of Sep 28 -->
&RFC2119; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-
&RFC2560; D.ietf-stir-passport-divert.xml"/>
&RFC5636;
&RFC7340; <!-- [I-D.draft-ietf-modern-teri] WG doc expired 2018 December -->
&RFC7258; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-
&RFC3261; D.ietf-modern-teri.xml"/>
&RFC6116;
&RFC6940; <!-- [I-D.draft-ietf-tls-subcerts] Active WG document, expires 2020 Dec -->
&RFC7748; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-
&RFC8224; D.ietf-tls-subcerts.xml"/>
&RFC8225;
&RFC8226; <!-- [I-D.draft-privacy-pass] Individual draft expired 2020 May -->
&RFC8174; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-
&RFC8446; D.privacy-pass.xml"/>
&I-D.ietf-stir-passport-divert;
&I-D.ietf-modern-teri; <!-- [I-D.draft-jennings-vipr-overview] Individual draft expired 2014 June -->
&I-D.ietf-tls-subcerts; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-
&I-D.privacy-pass; D.jennings-vipr-overview.xml"/>
&I-D.jennings-vipr-overview;
<reference anchor='REST'>
<front>
<title>Architectural Styles and the Design of Network-based Software Archi
tectures,
Chapter 5: Representational State Transfer</title>
<author initials='R' surname='Fielding' fullname="Roy Fielding">
<organization />
</author>
<date year='2010' />
</front>
<seriesInfo name='Ph.D. Dissertation,' value='University of California, Irvi
ne' />
<format type="pdf" target='http://www.ics.uci.edu/~fielding/pubs/dissertatio
n/fielding_dissertation.pdf'/>
</reference>
</references> </references>
<section anchor="Acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>The ideas
in this document came out of discussions with <contact fullname="Richard Barn
es"/> and
<contact fullname="Cullen Jennings"/>. We'd also like to thank
<contact fullname="Russ Housley"/>, <contact fullname="Chris Wendt"/>,
<contact fullname="Eric Burger"/>, <contact fullname="Mary Barnes"/>,
<contact fullname="Ben Campbell"/>, <contact fullname="Ted Huang"/>,
<contact fullname="Jonathan Rosenberg"/>, and <contact fullname="Robert Spark
s"/>
for helpful suggestions.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 98 change blocks. 
1093 lines changed or deleted 1147 lines changed or added

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