rfc8816xml2.original.xml   rfc8816.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!-- <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" cons
vim:et:ts=2:sw=2:spell:spelllang=en:tw=80 ensus="true" docName="draft-ietf-stir-oob-07" indexInclude="true" ipr="trust2009
<!-- This template is for creating an Internet Draft using xml2rfc, 02" number="8816" prepTime="2021-02-04T13:06:22" scripts="Common,Latin" sortRefs
which is available here: http://xml.resource.org. --> ="true" submissionType="IETF" symRefs="true" tocDepth="4" tocInclude="true" xml:
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ lang="en">
<link href="https://datatracker.ietf.org/doc/draft-ietf-stir-oob-07" rel="prev
<!ENTITY I-D.ietf-modern-teri SYSTEM "http://xml.resource.org/public/rfc/bibxml3 "/>
/reference.I-D.ietf-modern-teri.xml"> <link href="https://dx.doi.org/10.17487/rfc8816" rel="alternate"/>
<!ENTITY I-D.ietf-stir-passport-divert SYSTEM "http://xml.resource.org/public/rf <link href="urn:issn:2070-1721" rel="alternate"/>
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">
]>
<!--?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?-->
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<!--?rfc strict="yes" ?-->
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 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 ***** -->
<front> <front>
<!-- The abbreviated title is used in the page header - it is only necessary <title abbrev="STIR Out-of-Band">Secure Telephone Identity Revisited (STIR)
if the Out-of-Band Architecture and Use Cases</title>
full title is longer than 39 characters --> <seriesInfo name="RFC" value="8816" stream="IETF"/>
<author fullname="Eric Rescorla" initials="E." surname="Rescorla">
<title abbrev="STIR Out-of-Band">STIR Out-of-Band Architecture and Use Cases <organization showOnFrontPage="true">Mozilla</organization>
</title>
<author fullname="Eric Rescorla" initials="E.K." surn
ame="Rescorla">
<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" showOnFrontPage="true">Neustar, Inc.</organ
<organization abbrev="Neustar">Neustar, Inc.</organization> ization>
<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>US</country> <country>United States of America</country>
</postal> </postal>
<email>jon.peterson@team.neustar</email> <email>jon.peterson@team.neustar</email>
</address> </address>
</author> </author>
<date month="02" year="2021"/>
<date year="2020" />
<!-- <area>
ART
</area>-->
<keyword>SIP</keyword> <keyword>SIP</keyword>
<abstract pn="section-abstract">
<abstract> <t indent="0" pn="section-abstract-1">The Personal Assertion Token (PASSpo
<t> rT) 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>
<boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
"exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
>
<t indent="0" pn="section-boilerplate.1-1">
This document is not an Internet Standards Track specification; it i
s
published for informational purposes.
</t>
<t indent="0" pn="section-boilerplate.1-2">
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
</t>
<t indent="0" pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc8816" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t indent="0" pn="section-boilerplate.2-1">
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t indent="0" pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-introduction">
Introduction</xref></t>
</li>
<li pn="section-toc.1-1.2">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref der
ivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-terminology">T
erminology</xref></t>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref der
ivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-operating-envi
ronments">Operating Environments</xref></t>
</li>
<li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-dataflows">Dataflows</xref></t>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-use-cases">Use Cases</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.5.2">
<li pn="section-toc.1-1.5.2.1">
<t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent=
"5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-case-1-voip-to-pstn-ca
ll">Case 1: VoIP to PSTN Call</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2">
<t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent=
"5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-case-2-two-smart-pstn-
endpo">Case 2: Two Smart PSTN Endpoints</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3">
<t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent=
"5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-case-3-pstn-to-voip-ca
ll">Case 3: PSTN to VoIP Call</xref></t>
</li>
<li pn="section-toc.1-1.5.2.4">
<t indent="0" pn="section-toc.1-1.5.2.4.1"><xref derivedContent=
"5.4" format="counter" sectionFormat="of" target="section-5.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-case-4-gateway-out-of-
band">Case 4: Gateway Out-of-Band</xref></t>
</li>
<li pn="section-toc.1-1.5.2.5">
<t indent="0" pn="section-toc.1-1.5.2.5.1"><xref derivedContent=
"5.5" format="counter" sectionFormat="of" target="section-5.5"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-case-5-enterprise-call
-cent">Case 5: Enterprise Call Center</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-storing-and-retrieving-pass">Stori
ng and Retrieving PASSporTs</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.6.2">
<li pn="section-toc.1-1.6.2.1">
<t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent=
"6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-storage">Storage</xref
></t>
</li>
<li pn="section-toc.1-1.6.2.2">
<t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent=
"6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-retrieval">Retrieval</
xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-solution-architecture">Solution Ar
chitecture</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.7.2">
<li pn="section-toc.1-1.7.2.1">
<t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent=
"7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-credentials-and-phone-
numbe">Credentials and Phone Numbers</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2">
<t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent=
"7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-call-flow">Call Flow</
xref></t>
</li>
<li pn="section-toc.1-1.7.2.3">
<t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent=
"7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-security-analysis">Sec
urity Analysis</xref></t>
</li>
<li pn="section-toc.1-1.7.2.4">
<t indent="0" pn="section-toc.1-1.7.2.4.1"><xref derivedContent=
"7.4" format="counter" sectionFormat="of" target="section-7.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-substitution-attacks">
Substitution Attacks</xref></t>
</li>
<li pn="section-toc.1-1.7.2.5">
<t indent="0" pn="section-toc.1-1.7.2.5.1"><xref derivedContent=
"7.5" format="counter" sectionFormat="of" target="section-7.5"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-rate-control-for-cps-s
torag">Rate Control for CPS Storage</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-authentication-and-verifica">Authe
ntication and Verification Service Behavior for Out-of-Band</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.8.2">
<li pn="section-toc.1-1.8.2.1">
<t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent=
"8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-authentication-service
-as">Authentication Service (AS)</xref></t>
</li>
<li pn="section-toc.1-1.8.2.2">
<t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent=
"8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-verification-service-v
s">Verification Service (VS)</xref></t>
</li>
<li pn="section-toc.1-1.8.2.3">
<t indent="0" pn="section-toc.1-1.8.2.3.1"><xref derivedContent=
"8.3" format="counter" sectionFormat="of" target="section-8.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-gateway-placement-serv
ices">Gateway Placement Services</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" form
at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-example-https-interface-to-">Examp
le HTTPS Interface to the CPS</xref></t>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" fo
rmat="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-cps-discovery">CPS Discovery</xr
ef></t>
</li>
<li pn="section-toc.1-1.11">
<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" fo
rmat="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-encryption-key-lookup">Encryptio
n Key Lookup</xref></t>
</li>
<li pn="section-toc.1-1.12">
<t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" fo
rmat="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-iana-considerations">IANA Consid
erations</xref></t>
</li>
<li pn="section-toc.1-1.13">
<t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="13" fo
rmat="counter" sectionFormat="of" target="section-13"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-privacy-considerations">Privacy
Considerations</xref></t>
</li>
<li pn="section-toc.1-1.14">
<t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="14" fo
rmat="counter" sectionFormat="of" target="section-14"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-security-considerations">Securit
y Considerations</xref></t>
</li>
<li pn="section-toc.1-1.15">
<t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="15" fo
rmat="counter" sectionFormat="of" target="section-15"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-informative-references">Informat
ive References</xref></t>
</li>
<li pn="section-toc.1-1.16">
<t indent="0" pn="section-toc.1-1.16.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgment
s</xref></t>
</li>
<li pn="section-toc.1-1.17">
<t indent="0" pn="section-toc.1-1.17.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
resses</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
<t> <name slugifiedName="name-introduction">Introduction</name>
The STIR problem statement <xref target="RFC7340"/> describes widespread <t indent="0" pn="section-1-1">The STIR problem statement <xref target="RF
problems enabled by impersonation in the telephone network, including illegal ro C7340" format="default" sectionFormat="of" derivedContent="RFC7340"/>
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" sectionFormat="of" derivedContent="RFC3261">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" sectionFormat="of" derivedC
the calling party number (or, for native SIP cases, SIP URI) associated with th ontent="RFC8224"/> defines a SIP Identity header field
e originator of the call. capable of carrying <xref target="RFC8225" format="default" sectionFormat="of" d
</t><t> erivedContent="RFC8225">PASSporT objects</xref>
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 indent="0" pn="section-1-2">Not all telephone calls use SIP today, howe
ver, 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>
One or both of the endpoints is actually a PSTN endpoint. <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-1-3"
</t><t> >
Both of the endpoints are non-PSTN (SIP, Jingle, ...) but the call <li pn="section-1-3.1" derivedCounter="1.">
transits the PSTN at some point. One or both of the endpoints is actually a PSTN endpoint.
</t><t> </li>
Non-PSTN calls which do not transit the PSTN at all (such as native SIP e <li pn="section-1-3.2" derivedCounter="2.">Both of the endpoints are non
nd-to-end calls). -PSTN (SIP, Jingle, etc.) but the call transits the PSTN at some point.
</t></list></t><t> </li>
The first two categories represent the majority of telephone calls assoc <li pn="section-1-3.3" derivedCounter="3.">Non-PSTN calls that do not tr
iated with problems like illegal robocalling: many robocalls today originate on ansit the PSTN at all (such as native SIP end-to-end calls).
the Internet but terminate at PSTN endpoints. </li>
</ol>
<t indent="0" pn="section-1-4">The first two categories represent the maj
ority of telephone calls associated with problems like illegal robocalling: many
robocalls today originate on the Internet but terminate at PSTN endpoints.
However, the core network elements that operate the PSTN are legacy devices 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 indent="0" pn="section-1-5">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 indent="0" pn="section-1-6"> This capability also provides an ideal tra
and STIR adoption is ramping up. It permits early adopters to use the technology nsitional technology while in-band STIR adoption is ramping up. It permits early
even when intervening network adopters to use the technology 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 indent="0" pn="section-1-7">The techniques described in this document t
rget="RFC8225">PASSporT</xref> mechanism and the work of <xref target="RFC8224"/ herefore build on the
> to describe a way that <xref target="RFC8225" format="default" sectionFormat="of" derivedContent="RFC82
a PASSporT object created in the originating network of a call can reach 25">PASSporT</xref> mechanism and the work of <xref target="RFC8224" format="def
the terminating network even when it cannot be carried end-to-end in-band in the ault" sectionFormat="of" derivedContent="RFC8224"/> to describe a way that
call signaling. This relies on a PASSporT object created in the originating network of a call can reach the ter
a new service defined in this document called a Call Placement Service (C minating network even when it cannot be carried end-to-end in-band in the call s
PS) that permits the PASSporT object to be stored during call processing and ret ignaling. This relies on
rieved for verification purposes. a new service defined in this document called a Call Placement Service (CPS) tha
</t><t> t permits the PASSporT object to be stored during call processing and retrieved
Potential implementors should note that this document merely defines the for verification purposes.
operating environments in which this </t>
out-of-band STIR mechanism is intended to operate. It provides use case <t indent="0" pn="section-1-8">Potential implementors should note that thi
s, gives a broad description of the components and a potential solution architec s document merely defines the operating environments in which this
ture. out-of-band STIR mechanism is intended to operate. It provides use cases
Various environments may have their own security requirements: a , gives a broad description of the components, and a potential solution architec
public deployment of out-of-band STIR faces far greater challenges than a constr ture.
ained Various environments may have their own security requirements: a public deployme
intranetwork deployment. nt of out-of-band STIR faces far greater challenges than a constrained intra-net
work 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="include" removeInRFC="false" pn="section-2">
<section title="Terminology"> <name slugifiedName="name-terminology">Terminology</name>
<t>TThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t indent="0" pn="section-2-1">
"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 NOT</bcp14>", "<bcp14>SHOUL
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and o D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
nly when, they appear in all OT 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" format="default" sectionFormat="o
f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
mat="of" derivedContent="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-3">
<section title="Operating Environments"> <name slugifiedName="name-operating-environments">Operating Environments</
<t> name>
This section describes the environments in which the proposed out-of <t indent="0" pn="section-3-1">This section describes the environments in
-band STIR which the proposed out-of-band STIR mechanism is intended to operate. In the si
mechanism is intended to operate. In the simplest setting, Alice is mplest setting, Alice
calling Bob, and her call is routed through some set of gateways and/or the P calls Bob, and her call is routed through some set of gateways and/or the PST
STN N
which do not support end-to-end delivery of STIR. Both Alice that do not support end-to-end delivery of STIR. Both Alice
and Bob have smart devices which can access the Internet (perhaps enterprise and Bob have smart devices that can access the Internet (perhaps enterprise d
devices, or even end user ones), but they do not have evices, 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="" pn="section-3-2">
<figure> +---------+
<artwork><![CDATA[ / \
+---------+ +--- +---+
/ \ +----------+ / \ +----------+
+--- +---+ | | | Gateways | | |
+----------+ / \ +----------+ | Alice |&lt;-----&gt;| and/or |&lt;-----&gt;| Bob |
| | | Gateways | | | | (caller) | | PSTN | | (callee) |
| Alice |<----->| and/or |<----->| Bob | +----------+ \ / +----------+
| (caller) | | PSTN | | (callee) | +--- +---+
+----------+ \ / +----------+ \ /
+--- +---+ +---------+
\ / </artwork>
+---------+ <t indent="0" pn="section-3-3">In a more complicated setting, Alice and/or
]]></artwork> Bob may not have a smart or
</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="" pn="section-3-4">
<figure> +---------+
<artwork><![CDATA[ / \
+---------+ +--- +---+
/ \ +----------+ +--+ / \ +--+ +----------+
+--- +---+ | | | | | Gateways | | | | |
+----------+ +--+ / \ +--+ +----------+ | Alice |&lt;-|GW|-&gt;| and/or |&lt;-|GW|-&gt;| Bob |
| | | | | Gateways | | | | | | (caller) | | | | PSTN | | | | (callee) |
| Alice |<-|GW|->| and/or |<-|GW|->| Bob | +----------+ +--+ \ / +--+ +----------+
| (caller) | | | | PSTN | | | | (callee) | +--- +---+
+----------+ +--+ \ / +--+ +----------+ \ /
+--- +---+ +---------+
\ / </artwork>
+---------+ <t indent="0" pn="section-3-5">In such a case, Alice might have an analog
]]></artwork> (e.g., PSTN) connection to her
</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="include" removeInRFC="false" pn=
<section anchor="data" title="Dataflows"> "section-4">
<t>Because in these operating environments endpoints cannot pass cryptogra <name slugifiedName="name-dataflows">Dataflows</name>
phic information to one another directly <t indent="0" pn="section-4-1">Because in these operating environments, en
through signaling, any solution must dpoints cannot pass cryptographic information to one another directly
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 " sectionFormat="of" derivedContent="Section 11"/> for limitations of
this design.) this design.)
</t><t> </t>
This architecture does not mandate that any particular sort of entity ope <t indent="0" pn="section-4-2">This architecture does not mandate that any
rate a CPS, or mandate any means to discover a CPS. A CPS particular sort
could be run internally within a network, or made publicly available. One of entity operate a CPS or mandate any means to discover a CPS. A CPS
or more CPSes could be run by a carrier, as repositories for PASSporTs could be run internally within a network or made publicly available.
for calls sent to its customers, or a CPS could be built-in to an enterpr One or more CPSes could be run by a carrier, as repositories for PASSporTs
ise PBX, or even a smartphone. To the degree possible, it is for calls sent to its customers, or a CPS could be built into an enterprise
specified here generically, as an idea that may have applicability to a v PBX or even a smartphone. To the degree possible, it is
ariety of STIR deployments. specified here generically as an idea that may have applicability to a variety o
</t><t> f STIR deployments.
There are roughly two plausible dataflow architectures for the CPS: </t>
</t><t><list style="numbers"><t> <t indent="0" pn="section-4-3">There are roughly two plausible dataflow ar
The callee registers with the CPS. When the caller wishes to chitectures for the CPS:
</t>
<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4-4"
>
<li pn="section-4-4.1" derivedCounter="1.">The callee registers with the
CPS. When the caller wishes to
place a call to the callee, it sends the PASSporT to the CPS, 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 pn="section-4-4.2" derivedCounter="2.">The caller stores the PASSpor
T 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 indent="0" pn="section-4-5">While the first architecture is roughly iso
morphic 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="include" removeInRFC="false" pn=
<section anchor="uses" title="Use Cases"> "section-5">
<t> <name slugifiedName="name-use-cases">Use Cases</name>
The following are the motivating use cases for this mechanism. Bear in mi <t indent="0" pn="section-5-1">The following are the motivating use cases
nd that just as in <xref target="RFC8224"/> there may be multiple Identity heade for this mechanism. Bear in mind that,
rs in a single SIP just as in <xref target="RFC8224" format="default" sectionFormat="of" derivedCon
INVITE, so there may be multiple PASSporTs in this out-of-band mechanism tent="RFC8224"/>, there may be multiple Identity header fields in a single SIP
associated with a single call. For example, a SIP user agent might create a PASS INVITE, so there may be multiple PASSporTs in this out-of-band mechanism associa
porT for a call with an end user ted with a single call. For example, a SIP user agent might create a PASSporT fo
credential, and as the call exits the originating administrative domain t r a call with an end-user
he network authentication service might create its own PASSporT for the same cal credential, and as the call exits the originating administrative domain,
l. As such, these use cases may overlap the network authentication service might create its own PASSporT for the same ca
in the processing of a single call. ll. As such, these use cases may overlap
</t> in the processing of a single call.
<section anchor="case-ip-pstn" title="Case 1: VoIP to PSTN Call"> </t>
<t> <section anchor="case-ip-pstn" numbered="true" toc="include" removeInRFC="
A call originates in a SIP environment in a STIR-aware administra false" pn="section-5.1">
tive domain. The local authentication service for that administrative domain cre <name slugifiedName="name-case-1-voip-to-pstn-call">Case 1: VoIP to PSTN
ates a PASSporT which is carried Call</name>
in band in the call per <xref target="RFC8224"/>. The call is rou <t indent="0" pn="section-5.1-1">A call originates in a SIP environment
ted out of the originating administrative domain and reaches a gateway to the PS in a STIR-aware administrative domain. The local authentication service for that
TN. administrative domain creates a PASSporT that is carried
Eventually, the call will terminate on a mobile smartphone that s in band in the call per <xref target="RFC8224" format="default" sectionFormat="o
upports this out-of-band mechanism. f" derivedContent="RFC8224"/>. The call is routed out of the originating adminis
</t><t> trative domain and reaches a gateway to the PSTN.
In this use case, the originating authentication service can store t Eventually, the call will terminate on a mobile smartphone that supports this ou
he PASSporT with the appropriate CPS (per the practices of t-of-band mechanism.
<xref target="cps"/>) for the target telephone number as a fallback </t>
in case SIP signaling will not <t indent="0" pn="section-5.1-2">In this use case, the originating authe
reach end-to-end. When the destination mobile smartphone receives ntication service
the call over the PSTN, it consults the CPS and discovers a PASSporT from the o can store the PASSporT with the appropriate CPS (per the practices of
riginating telephone number waiting for it. <xref target="cps" format="default" sectionFormat="of" derivedContent="Section 1
It uses this PASSporT to verify the calling party number. 0"/>) for the target telephone number
</t> as a fallback in case SIP signaling will not reach end-to-end. When
</section> the destination mobile smartphone receives the call over the PSTN, it
<section anchor="case-pstn-pstn-gw" title="Case 2: Two Smart PSTN consults the CPS and discovers a PASSporT from the originating telephone number
endpoints"> waiting for it.
<t> It uses this PASSporT to verify the calling party number.
A call originates with an enterprise PBX that has both Internet a </t>
ccess and a built-in gateway to the PSTN, which communicates through traditional </section>
telephone signaling protocols. The PBX immediately routes the call to the PSTN, <section anchor="case-pstn-pstn-gw" numbered="true" toc="include" removeIn
but before it does, it provisions RFC="false" pn="section-5.2">
a PASSporT on the CPS associated with the target telephone number <name slugifiedName="name-case-2-two-smart-pstn-endpo">Case 2: Two Smart
. PSTN Endpoints</name>
</t><t> <t indent="0" pn="section-5.2-1">A call originates with an enterprise PB
After normal PSTN routing, the call lands on a smart mobile hands X that has both
et that supports the STIR out-of-band mechanism. It queries the appropriate CPS Internet access and a built-in gateway to the PSTN, which communicates
over the Internet to determine if a call has been placed to it through traditional telephone signaling protocols.
by a STIR-aware device. It finds the PASSporT provisioned by the The PBX immediately routes the call to the PSTN, but before it does,
enterprise PBX and uses it to verify the calling party number. it provisions a PASSporT on the CPS associated with the target telephone number.
</t> </t>
</section> <t indent="0" pn="section-5.2-2">After normal PSTN routing, the call lan
<section anchor="case-pstn-ip" title="Case 3: PSTN to VoIP Call"> ds on a smart mobile handset that supports the STIR out-of-band mechanism. It qu
<t> eries the appropriate CPS over the Internet to determine if a call has been plac
A call originates with an enterprise PBX that has both Internet a ed to it
ccess and a built-in gateway to the PSTN. It will immediately route the call to by a STIR-aware device. It finds the PASSporT provisioned by the
the PSTN, but before it does, it provisions enterprise PBX and uses it to verify the calling party number.
a PASSporT with the CPS associated with the target telephone numb </t>
er. However, it turns out that the call will eventually route through the PSTN t </section>
o an Internet gateway, which will translate this into a SIP <section anchor="case-pstn-ip" numbered="true" toc="include" removeInRFC="
call and deliver it to an administrative domain with a STIR verif false" pn="section-5.3">
ication service. <name slugifiedName="name-case-3-pstn-to-voip-call">Case 3: PSTN to VoIP
</t><t> Call</name>
In this case, there are two subcases for how the PASSporT might b <t indent="0" pn="section-5.3-1">A call originates with an enterprise PB
e retrieved. In subcase 1, X that has both
the Internet gateway that receives the call from the PSTN could q Internet access and a built-in gateway to the PSTN. It will immediately
uery the appropriate CPS to determine if the original caller created and provisi route the call to the PSTN, but before it does, it provisions
oned a PASSporT for this call. If so, a PASSporT with the CPS associated with the target telephone number.
it can retrieve the PASSporT and, when it creates a SIP INVITE fo However, it turns out that the call will eventually route through
r this call, add a corresponding Identity header field per <xref target="RFC8224 the PSTN to an Internet gateway, which will translate this into a SIP
"/>. When the SIP INVITE reaches call and deliver it to an administrative domain with a STIR verification service
the destination administrative domain, it will be able to verify .
the PASSporT normally. Note that to avoid discrepancies with the Date header fie </t>
ld value, only full-form PASSporT should be used for this purpose. In <t indent="0" pn="section-5.3-2">In this case, there are two subcases fo
subcase 2, the gateway does not retrieve the PASSporT itself, but r how the PASSporT
instead the verification service at the destination administrative domain does might be retrieved. In subcase 1, the Internet gateway that receives
so. Subcase 1 would perhaps be valuable for deployments where the call from the PSTN could query the appropriate CPS to determine
the destination administrative domain supports in-band STIR but n if the original caller created and provisioned a PASSporT for this call. If so,
ot out-of-band STIR. it can retrieve the PASSporT and, when it creates a SIP INVITE for
</t> this call, add a corresponding Identity header field per
</section> <xref target="RFC8224" format="default" sectionFormat="of" derivedContent="RFC82
<section anchor="case-gateways" title="Case 4: Gateway Out-of-ban 24"/>. When the SIP INVITE reaches
d"> the destination administrative domain, it will be able to verify the
<t> PASSporT normally. Note that to avoid discrepancies with the Date
A call originates in the SIP world in a STIR-aware administrative header field value, only a full-form PASSporT should be used for this purpose. I
domain. The local authentication service for that administrative domain creates n
a PASSporT which is carried subcase 2, the gateway does not retrieve the PASSporT itself, but
in band in the call per <xref target="RFC8224"/>. The call is rou instead the verification service at the destination administrative
ted out of the originating administrative domain and eventually reaches a gatewa domain does so. Subcase 1 would perhaps be valuable for deployments where
y to the PSTN. the destination administrative domain supports in-band STIR but not out-of-band
</t><t> STIR.
In this case, the originating authentication service does not sup </t>
port the out-of-band mechanism, so instead the gateway to the PSTN extracts the </section>
PASSporT from the SIP request and provisions it to the CPS. (When the call reach <section anchor="case-gateways" numbered="true" toc="include" removeInRFC=
es the gateway to the PSTN, the gateway might first check the CPS to see if a PA "false" pn="section-5.4">
SSporT object had already been provisioned for this call, and only provision a P <name slugifiedName="name-case-4-gateway-out-of-band">Case 4: Gateway Ou
ASSporT if none is present). t-of-Band</name>
</t><t> <t indent="0" pn="section-5.4-1">A call originates in the SIP world in a
Ultimately, the call may terminate on the PSTN, or be routed back STIR-aware administrative domain.
to a SIP environment. In the former case, perhaps the destination endpoint quer The local authentication service for that administrative domain creates a PASSpo
ies the CPS to retrieve the PASSporT provisioned by the first gateway. Or if the rT that is carried
call ultimately returns to a SIP environment, it might be the gateway from the in band in the call per <xref target="RFC8224" format="default" sectionFormat="o
PSTN back to the Internet that retrieves the PASSporT from the CPS and attaches f" derivedContent="RFC8224"/>. The call is routed
it to the new SIP INVITE it creates, or it might be the terminating administrati out of the originating administrative domain and eventually reaches a gateway to
ve domain's verification service that checks the CPS when an INVITE arrives with the PSTN.
no Identity header field. Either way the PASSporT can survive the gap in SIP co </t>
verage caused by the PSTN leg of the call. <t indent="0" pn="section-5.4-2">In this case, the originating authentic
</t> ation service does not support the out-of-band mechanism, so instead the gateway
</section> to the PSTN extracts the PASSporT from the SIP request and provisions it to the
<section anchor="case-enterprise" title="Case 5: Enterprise Call CPS. (When the call reaches the gateway to the PSTN, the gateway might first ch
Center"> eck the CPS to see if a PASSporT object had already been provisioned for this ca
<t> ll, and only provision a PASSporT if none is present).
A call originates from a mobile user, and a STIR authentication s </t>
ervice operated by their carrier creates a PASSporT for the call. As the carrier <t indent="0" pn="section-5.4-3">Ultimately, the call may terminate on t
forwards the call via SIP, it attaches the PASSporT to the SIP call with an Ide he PSTN or be routed back to a SIP environment. In the former case, perhaps the
ntity header field. As a fallback in case the call will not go end-to-end over S destination endpoint queries the CPS to retrieve the PASSporT provisioned by the
IP, the carrier also stores the PASSporT in a CPS. first gateway. If the call ultimately returns to a SIP environment, it might be
</t><t> the gateway from the PSTN back to the Internet that retrieves the PASSporT from
The call is then routed over SIP for a time, before it transition the CPS and attaches it to the new SIP INVITE it creates, or it might be the te
s to the PSTN and ultimately is handled by a legacy PBX at a high-volume call ce rminating administrative domain's verification service that checks the CPS when
nter. The call center supports the out-of-band service, and has a high-volume in an INVITE arrives with no Identity header field. Either way, the PASSporT can su
terface to a CPS to retrieve PASSporTs for incoming calls; agents at the call ce rvive the gap in SIP coverage caused by the PSTN leg of the call.
nter use a general purpose computer to manage inbound calls and can receive STIR </t>
notifications through it. When the PASSporT arrives at the CPS, it is sent thro </section>
ugh a subscription/notification interface to a system that can correlate incomin <section anchor="case-enterprise" numbered="true" toc="include" removeInRF
g calls with valid PASSporTs. The call center agent sees that a valid call from C="false" pn="section-5.5">
the originating number has arrived. <name slugifiedName="name-case-5-enterprise-call-cent">Case 5: Enterpris
</t> e Call Center</name>
</section> <t indent="0" pn="section-5.5-1">A call originates from a mobile user, a
nd a STIR authentication service operated by their carrier creates a PASSporT fo
</section> r the call. As the carrier forwards the call via SIP, it attaches the PASSporT t
o the SIP call with an Identity header field. As a fallback in case the call wil
<section anchor="authz" title="Storing and Retrieving PASSporTs"> l not go end-to-end over SIP, the carrier also stores the PASSporT in a CPS.
<t>The use cases show a variety of entities accessing the CPS to store and </t>
retrieve PASSporTs. The question of how the CPS authorizes the storage <t indent="0" pn="section-5.5-2">The call is then routed over SIP for a
and retrieval of PASSporT is thus a key design decision in the architec time, before it
ture. transitions to the PSTN and ultimately is handled by a legacy PBX at a
The STIR architecture assumes that service providers and in some cases high-volume call center. The call center supports the out-of-band service,
end user devices will have credentials suitable for attesting authority over tel and has a high-volume interface to a CPS to retrieve PASSporTs for incoming
ephone numbers per <xref target="RFC8226"/>. calls; agents at the call center use a general purpose computer to manage
These credentials provide the most obvious way that a CPS can authorize inbound calls and can receive STIR notifications through it. When the PASSporT
the storage and retrieval of PASSporTs. However, as use cases 3, 4 and 5 in <xr arrives at the CPS, it is sent through a subscription/notification interface
ef target="uses"/> show, it may sometimes make sense for the entity to a system that can correlate incoming calls with valid PASSporTs. The call
storing or retrieving PASSporTs to be an intermediary rather than a dev center agent sees that a valid call from the originating number has arrived.
ice associated with either the originating or terminating side of a call, and th </t>
ose intermediaries often would not have access to STIR credentials covering the </section>
telephone numbers in question. Requiring authorization based on a credential to </section>
store PASSporTs is therefore undesirable, though potentially acceptable if suffi <section anchor="authz" numbered="true" toc="include" removeInRFC="false" pn
cient steps are taken to mitigate any privacy risk of leaking data. ="section-6">
</t><t> <name slugifiedName="name-storing-and-retrieving-pass">Storing and Retriev
It is an explicit design goal of this mechanism to minimize the potenti ing PASSporTs</name>
al privacy exposure of using a CPS. Ideally, the out-of-band <t indent="0" pn="section-6-1">The use cases show a variety of entities ac
mechanism should not result in a worse privacy situation than in-band < cessing the CPS to
xref target="RFC8224"/> STIR: for in-band, we might say that a SIP entity is aut store and retrieve PASSporTs. The question of how the CPS authorizes the
horized to receive a PASSporT if it storage and retrieval of PASSporTs is thus a key design decision in the architec
is an intermediate or final target of the routing of a SIP request. As ture.
the originator of a call cannot necessarily predict the routing path a call will The STIR architecture assumes that service providers and, in some cases,
follow, an out-of-band mechanism could conceivably end-user devices will have credentials suitable for attesting authority
even improve on the privacy story. over telephone numbers per <xref target="RFC8226" format="default" sectionFormat
</t><t> ="of" derivedContent="RFC8226"/>.
Broadly, the architecture recommended here thus is one focused on permi These credentials provide the most obvious way that a CPS can authorize
tting any entity to store the storage and retrieval of PASSporTs. However, as use cases 3, 4, and 5
encrypted PASSporTs at the CPS, indexed under the called number. PASSpo in <xref target="uses" format="default" sectionFormat="of" derivedContent="Secti
rTs will be encrypted with a public key associated with the called number, so th on 5"/> show, it may sometimes make sense
ese PASSporTs may safely be retrieved by any entity, as for the entity storing or retrieving PASSporTs to be an intermediary rather
only holders of the corresponding private key will be able to decrypt t than a device associated with either the originating or terminating side of
he PASSporT. This also prevents the CPS itself from learning the contents of PA a call; those intermediaries often would not have access to STIR
SSporTs, and thus metadata about calls in progress, which makes the CPS a less a credentials covering the telephone numbers in question. Requiring authorization
ttractive target for pervasive monitoring (see <xref target="RFC7258"/>). As a f based on a credential to store PASSporTs is therefore undesirable, though
irst step, transport-level security can provide confidentiality from eavesdroppe potentially acceptable if sufficient steps are taken to mitigate any privacy
rs for both the storing and retrieval of PASSporTs. To bolster the privacy story risk of leaking data.
, prevent denial-of-service flooding of the CPS, and to complicate traffic analy </t>
sis, a few additional mechanisms are also recommended below. <t indent="0" pn="section-6-2">It is an explicit design goal of this mecha
nism to minimize
</t> the potential privacy exposure of using a CPS. Ideally, the out-of-band
<section anchor="stor" title="Storage"> mechanism should not result in a worse privacy situation than in-band
<t> STIR <xref target="RFC8224" format="default" sectionFormat="of" derivedContent="
There are a few dimensions to authorizing the storage of PASSporTs. Enc RFC8224"/>: for in-band, we might say
rypting PASSporTs prior to storage entails that a CPS has no way to tell if a PA that a SIP entity is authorized to receive a PASSporT if it is an intermediate
SSporT is valid; it simply conveys encrypted or final target of the routing of a SIP request. As the originator of a
blocks that it cannot access itself, and can make no authorization deci call cannot necessarily predict the routing path a call will follow, an
sion based on the PASSporT contents. There is certainly no prospect for the CPS out-of-band mechanism could conceivably even improve on the privacy story.
to verify the PASSporTs itself. </t>
</t><t> <t indent="0" pn="section-6-3">Broadly, the architecture recommended here
Note that this architecture requires clients that store PASSporTs to ha thus is one focused
ve access to an encryption key associated with the intended called party to be u on permitting any entity to store encrypted PASSporTs at the CPS, indexed
sed to encrypt the PASSporT. Discovering this key requires the existence of a ke under the called number. PASSporTs will be encrypted with a public key
y lookup service (see <xref target="lookup"/>); depending on how the CPS is arch associated with the called number, so these PASSporTs may safely be retrieved
itected, however, some kind of key store or repository could be implemented adja by any entity because only holders of the corresponding private key will be
cent to it, and perhaps even incorporated into its operation. Key discovery is m able to decrypt the PASSporT. This also prevents the CPS itself from
ade more complicated by the fact that there can potentially be multiple entities learning the contents of PASSporTs, and thus metadata about calls in
that have progress, which makes the CPS a less attractive target for pervasive
authority over a telephone number: a carrier, a reseller, an enterprise monitoring (see <xref target="RFC7258" format="default" sectionFormat="of" deriv
, and an end user might all have credentials permitting them to attest that they edContent="RFC7258"/>). As a first
are allowed to originate calls from a number, say. PASSporTs for out-of-band us step, transport-level security can provide confidentiality from eavesdroppers
e therefore might need to be encrypted with multiple keys in the hopes that one for both the storing and retrieval of PASSporTs. To bolster the privacy story,
will be decipherable by the relying party. to prevent denial-of-service flooding of the CPS, and to complicate traffic
</t><t> analysis, a few additional mechanisms are also recommended below.
Again, the most obvious way to authorize storage is to require the orig </t>
inator to authenticate themselves to the CPS with their STIR credential. However <section anchor="stor" numbered="true" toc="include" removeInRFC="false" p
, since the call is indexed at the CPS under the called number, this can weaken n="section-6.1">
the privacy story of the architecture, as it reveals to the CPS both the identit <name slugifiedName="name-storage">Storage</name>
y of the caller and the callee. Moreover, it does not work for the gateway use c <t indent="0" pn="section-6.1-1">There are a few dimensions to authorizi
ases described above; to support those use cases, we must effectively allow any ng the storage of PASSporTs.
entity to store PASSporTs at a CPS. This does not degrade the anti-impersonation Encrypting PASSporTs prior to storage entails that a CPS has no way to tell
security of STIR, because entities who do not possess the necessary credentials if a PASSporT is valid; it simply conveys encrypted blocks that it cannot
to sign the PASSporT will not be able to create PASSporTs that will be treated access itself and can make no authorization decision based on the PASSporT
as valid by verifiers. In this architecture, it does not matter whether the CPS contents. There is certainly no prospect for the CPS to verify the PASSporTs its
received a PASSporT from the authentication service that created it or from an i elf.
ntermediary gateway downstream in the routing path as in case 4 above. However, </t>
if literally anyone can store PASSporTs in the CPS, an attacker could easily flo <t indent="0" pn="section-6.1-2">Note that this architecture requires cl
od the CPS with millions of bogus PASSporTs indexed under a calling number, and ients that store PASSporTs
thereby prevent the called to have access to an encryption key associated with the intended called party
party from finding a valid PASSporT for an incoming call buried in a ha to be used to encrypt the PASSporT. Discovering this key requires the existence
ystack of fake entries. of a key lookup service (see <xref target="lookup" format="default" sectionForma
</t><t> t="of" derivedContent="Section 11"/>),
The solution architecture must therefore include some sort of traffic c depending on how the CPS is architected; however, some kind of key store or
ontrol system to prevent flooding. Preferably, this should not require authentic repository could be implemented adjacent to it and perhaps even incorporated
ating the source, as this will reveal to the CPS both the source and destination into its operation. Key discovery is made more complicated by the fact that
of traffic. A potential solution is discussed below in <xref target="rate-contr there can potentially be multiple entities that have
ol"/>. authority over a telephone number: a carrier, a reseller, an enterprise,
</t> and an end user might all have credentials permitting them to attest that they
</section> are allowed to originate calls from a number, say. PASSporTs for out-of-band use
<section anchor="retr" title="Retrieval"> therefore might need to be encrypted with multiple keys in the hopes that one
<t> will be decipherable by the relying party.
For retrieval of PASSporTs, this architecture assumes that clients will </t>
contact the CPS through some sort of polling or notification interface to recei <t indent="0" pn="section-6.1-3">Again, the most obvious way to authoriz
ve all e storage is to require
current PASSporTs for calls destined to a particular telephone number, the originator to authenticate themselves to the CPS with their STIR credential.
or block of numbers. However, since the call is indexed at the CPS under the called number,
</t> this can weaken the privacy story of the architecture, as it reveals to
<t> the CPS both the identity of the caller and the callee. Moreover, it does not wo
As PASSporTs stored at the CPS are encrypted with a key belonging to th rk
e intended destination, the CPS can safely for the gateway use cases described above; to support those use cases, we must
allow anyone to download PASSporTs for a called number without much fea effectively allow any entity to store PASSporTs at a CPS. This does not degrade
r of compromising private information about calls in progress - provided that th the anti-impersonation security of STIR, because entities who do not possess
e CPS always returns at least one encrypted blob in response to a request, even the necessary credentials to sign the PASSporT will not be able to create
if there was no call in progress. Otherwise, entities could poll the CPS constan PASSporTs that will be treated as valid by verifiers. In this architecture,
tly, or eavesdrop on traffic, to learn whether or not calls were in progress. Th it does not matter whether the CPS received a PASSporT from the authentication
e CPS MUST generate at least one unique and plausible encrypted response to all service that created it or from an intermediary gateway downstream in the
retrieval requests, and these dummy encrypted PASSporTs MUST NOT be repeated for routing path as in case 4 above. However, if literally anyone can store
later calls. An encryption scheme needs to be carefully chosen to make messages PASSporTs in the CPS, an attacker could easily flood the CPS with millions
look indistinguishable from random when encrypted, so that information about ca of bogus PASSporTs indexed under a calling number, and thereby prevent the calle
lled party is not discoverable from legitimate encrypted PASSporTs. d
</t><t> party from finding a valid PASSporT for an incoming call buried in a haystack of
Because the entity placing a call may discover multiple keys associated fake entries.
with the called party number, multiple valid PASSporTs may be stored in the CPS </t>
. A particular called party who retrieves PASSporTs from the CPS may have access <t indent="0" pn="section-6.1-4">The solution architecture must therefor
to only one of those keys. Thus, the presence of one or more PASSporTs that the e include some sort of traffic
called party cannot decrypt - which would be indistinguishable from the "dummy" control system to prevent flooding. Preferably, this should not require
PASSporTS created by the CPS when no calls are in progress - does not entail th authenticating the source, as this will reveal to the CPS both the source and
at there is no call in progress. A retriever likely will need to decrypt all PAS destination of traffic. A potential solution is discussed below in <xref target=
SporTs retrieved from the CPS, and may find only one that is valid. "rate-control" format="default" sectionFormat="of" derivedContent="Section 7.5"/
</t><t> >.
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 </section>
ave no hope of decrypting. Implementations could even allow a callee to request <section anchor="retr" numbered="true" toc="include" removeInRFC="false" p
PASSporTs for a range or prefix of numbers: a trade-off where that callee is wil n="section-6.2">
ling to sift through bulk quantities of undecryptable PASSporTs for the sake of <name slugifiedName="name-retrieval">Retrieval</name>
hiding from the CPS what numbers it controls. <t indent="0" pn="section-6.2-1">For retrieval of PASSporTs, this archit
</t><t> ecture assumes that clients will
Note that in out-of-band call forwarding cases, special behavior is req contact the CPS through some sort of polling or notification interface to receiv
uired to manage the relationship between PASSporTs using the diversion extension e all
<xref target="I-D.ietf-stir-passport-divert"/>. The originating authentication current PASSporTs for calls destined to a particular telephone number, or block
service would encrypt the initial PASSporT with the public encryption key of the of numbers.
intended destination, but once a call is forwarded, it may go to a destination </t>
that does not possess the corresponding private key and thus could not decrypt t <t indent="0" pn="section-6.2-2">As PASSporTs stored at the CPS are encr
he original PASSporT. This requires the retargeting entity to generate encrypted ypted with a key belonging
PASSporTs that show a secure chain of diversion: a retargeting storer SHOULD us to the intended destination, the CPS can safely allow anyone to download PASSpor
e the "div-o" PASSporT type, with its "opt" extension, as specified in <xref ta Ts
rget="I-D.ietf-stir-passport-divert"/> in order to nest the original PASSporT wi for a called number without much fear of compromising private information
thin the encrypted diversion PASSporT. about calls in progress -- provided that the CPS always returns at least one
</t> encrypted blob in response to a request, even if there was no call in progress.
</section> Otherwise, entities could poll the CPS constantly, or eavesdrop on traffic,
</section> to learn whether or not calls were in progress. The CPS <bcp14>MUST</bcp14> gene
rate
<section anchor="arch" title="Solution Architecture"> at least one unique and plausible encrypted response to all retrieval requests,
<t>In this section, we discuss a high-level architecture for providing the and these dummy encrypted PASSporTs <bcp14>MUST NOT</bcp14> be repeated for
service later calls. An encryption scheme needs to be carefully chosen to make messages
look indistinguishable from random when encrypted, so that information about the
called party is not discoverable from legitimate encrypted PASSporTs.
</t>
<t indent="0" pn="section-6.2-3">Because the entity placing a call may d
iscover multiple keys
associated with the called party number, multiple valid PASSporTs may be
stored in the CPS. A particular called party who retrieves PASSporTs from
the CPS may have access to only one of those keys. Thus, the presence of
one or more PASSporTs that the called party cannot decrypt -- which would
be indistinguishable from the "dummy" PASSporTs created by the CPS when
no calls are in progress - does not entail that there is no call in progress.
A retriever likely will need to decrypt all PASSporTs retrieved from the CPS,
and may find only one that is valid.
</t>
<t indent="0" pn="section-6.2-4">In order to prevent the CPS from learni
ng the numbers that a callee
controls, callees might also request PASSporTs for numbers that they do not own,
that they have no hope of decrypting. Implementations could even allow a callee
to request PASSporTs for a range or prefix of numbers: a trade-off where that
callee is willing to sift through bulk quantities of undecryptable PASSporTs
for the sake of hiding from the CPS which numbers it controls.
</t>
<t indent="0" pn="section-6.2-5">Note that in out-of-band call forwardin
g cases, special behavior is
required to manage the relationship between PASSporTs using the diversion
extension <xref target="I-D.ietf-stir-passport-divert" format="default" sectionF
ormat="of" derivedContent="PASSPORT-DIVERT"/>.
The originating authentication service encrypts the initial PASSporT with the
public encryption key of the intended destination, but once a call is forwarded,
it may go to a destination that does not possess the corresponding private key
and thus could not decrypt the original PASSporT. This requires the retargeting
entity to generate encrypted PASSporTs that show a secure chain of diversion:
a retargeting storer <bcp14>SHOULD</bcp14> use the "div-o" PASSporT type,
with its "opt" extension, as specified in
<xref target="I-D.ietf-stir-passport-divert" format="default" sectionFormat="of"
derivedContent="PASSPORT-DIVERT"/>, in order to nest
the original PASSporT within the encrypted diversion PASSporT.
</t>
</section>
</section>
<section anchor="arch" numbered="true" toc="include" removeInRFC="false" pn=
"section-7">
<name slugifiedName="name-solution-architecture">Solution Architecture</na
me>
<t indent="0" pn="section-7-1">In this section, we discuss a high-level ar
chitecture 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" sectionFormat="of" derivedContent="Sect
</t> ion 9"/>.
<section anchor="phone" title="Credentials and Phone Numbers"> </t>
<t> <section anchor="phone" numbered="true" toc="include" removeInRFC="false"
We start from the premise of the <xref target="RFC7340">STIR problem statemen pn="section-7.1">
t</xref> that phone numbers can be <name slugifiedName="name-credentials-and-phone-numbe">Credentials and P
associated with credentials which can be used to attest hone Numbers</name>
<t indent="0" pn="section-7.1-1">We start from the premise of the
<xref target="RFC7340" format="default" sectionFormat="of" derivedContent="RF
C7340">STIR problem statement</xref> that phone 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" sectionFormat= "of" derivedContent="RFC8226"/> 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="include" removeInRFC="false"
<t> pn="section-7.2">
An overview of the basic calling and verification process is show <name slugifiedName="name-call-flow">Call Flow</name>
n <t indent="0" pn="section-7.2-1">An overview of the basic calling and ve
rification process is shown
below. In this diagram, we assume that Alice has the number below. In this diagram, we assume that Alice has the number
+1.111.555.1111 and Bob has the number +2.222.555.2222. +1.111.555.1111 and Bob has the number +2.222.555.2222.
</t> </t>
<figure> <artwork name="" type="" align="left" alt="" pn="section-7.2-2">
<artwork><![CDATA[
Alice Call Placement Service Bob Alice Call Placement Service Bob
-------------------------------------------------------------------- --------------------------------------------------------------------
Store Encrhypted PASSporT for 2.222.555.2222 -&gt; Store Encrypted PASSporT for 2.222.555.2222 -&gt;
Call from 1.111.555.1111 ------------------------------------------> Call from 1.111.555.1111 ------------------------------------------&gt;
<-------------- Request PASSporT(s) &lt;-------------- Request PASSporT(s)
for 2.222.555.2222 for 2.222.555.2222
Obtain Encrypted PASSporT --------> Obtain Encrypted PASSporT --------&gt;
(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 indent="0" pn="section-7.2-3">When Alice wishes to make a call to Bob
<t> , she contacts the CPS and
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 indent="0" pn="section-7.2-4">When Alice places the call, Bob's phone
When Alice places the call, Bob's phone would usually ring and display would usually ring and display
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="include" removeInRFC="false" pn
<section anchor="sec" title="Security Analysis"> ="section-7.3">
<t> <name slugifiedName="name-security-analysis">Security Analysis</name>
The primary attack we seek to prevent is an attacker convincing the <t indent="0" pn="section-7.3-1">The primary attack we seek to prevent i
s 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" indent="adaptive" start="1" pn="section-7.
target is in progress. 3-2">
</t><t> <li pn="section-7.3-2.1" derivedCounter="1.">The attacker wishes to im
The attacker wishes to substitute himself for an existing call setup. personate a target when no call from that
</t></list></t><t> target is in progress.
If an attacker can inject fake PASSporTs into the CPS or in the </li>
<li pn="section-7.3-2.2" derivedCounter="2.">The attacker wishes to su
bstitute himself for an existing call setup.
</li>
</ol>
<t indent="0" pn="section-7.3-3">If an attacker can inject fake PASSporT
s 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" sectionFormat="of" derivedContent=
Any attacker who is aware of calls in progress can attempt to mount a race to "Section 7.1"/>), this should not arise in ordinary 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" sectionFormat="of" derive
the PASSporT at the CPS is RECOMMENDED. dContent="Section 7.4"/>. For privacy and robustness reasons,
</t><t> using <xref target="RFC8446" format="default" sectionFormat="of" derivedConte
The entire system depends on the security of the credential nt="RFC8446">TLS</xref> on the originating
side when storing the PASSporT at the CPS is <bcp14>RECOMMENDED</bcp14>.
</t>
<t indent="0" pn="section-7.3-4">The entire system depends on the securi
ty 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" sectionFormat="of" derivedContent="RFC8224"/>.
</t><t> </t>
A secondary attack we must also prevent is denial-of-service against the <t indent="0" pn="section-7.3-5">A secondary attack we must also prevent
CPS, which requires some form of rate control solution that will not degrade the is denial-of-service against the CPS, which requires some form of rate control
privacy properties of the architecture. solution that will not degrade the privacy properties of the architecture.
</t> </t>
</section> </section>
<section anchor="sub" title="Substitution Attacks"> <section anchor="sub" numbered="true" toc="include" removeInRFC="false" pn
<t> ="section-7.4">
All the receipt of the PASSporT from the CPS proves to the called party <name slugifiedName="name-substitution-attacks">Substitution Attacks</na
me>
<t indent="0" pn="section-7.4-1">All that the receipt of the PASSporT fr
om the CPS proves to the called 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="" pn="section-7.4-2">
<artwork><![CDATA[
Attacker Callback Service CPS Bob Attacker Callback Service CPS Bob
-------------------------------------------------------------------- --------------------------------------------------------------------
Place call to Bob ----------> Place call to Bob ----------&gt;
(from 111.555.1111) (from 111.555.1111)
Store PASSporT for Store PASSporT for
CS:Bob -------------> CS:Bob -------------&gt;
Call from Attacker (forged CS caller-id info) --------------------> Call from Attacker (forged CS caller-id info) --------------------&gt;
Call from CS ------------------------> X Call from CS ------------------------&gt; X
<-- Retrieve PASSporT &lt;-- Retrieve PASSporT
for CS:Bob for CS:Bob
PASSporT for CS:Bob ------------------------> PASSporT for CS:Bob ------------------------&gt;
[Ring phone with callerid = [Ring phone with callerid =
111.555.1111] 111.555.1111]
]]></artwork> </artwork>
</figure><t> <t indent="0" pn="section-7.4-3">In order to mount this attack, the atta
In order to mount this attack, the attacker contacts the Callbac cker contacts the Callback
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 indent="0" pn="section-7.4-4">
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 indent="0" pn="section-7.4-5">
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="include" removeInRFC="
<t> false" pn="section-7.5">
In order to prevent the flooding of a CPS with bogus PASSporTs, we prop <name slugifiedName="name-rate-control-for-cps-storag">Rate Control for
ose the use of "blind signatures" (see <xref target="RFC5636"/>). A sender will CPS Storage</name>
initially authenticate to the CPS using its STIR credentials, and acquire a sign <t indent="0" pn="section-7.5-1">In order to prevent the flooding of a C
ed token from the CPS that will be presented later when storing a PS with bogus PASSporTs,
PASSporT. The flow looks as follows: we propose the use of "blind signatures" (see <xref target="RFC5636" format="def
</t> ault" sectionFormat="of" derivedContent="RFC5636"/>).
<figure> A sender will initially authenticate to the CPS using its STIR credentials
<artwork><![CDATA[ and acquire a signed token from the CPS that will be presented later
when storing a PASSporT. The flow looks as follows:
</t>
<artwork name="" type="" align="left" alt="" pn="section-7.5-2">
Sender CPS Sender CPS
Authenticate to CPS ---------------------> Authenticate to CPS ---------------------&gt;
Blinded(K_temp) -------------------------> Blinded(K_temp) -------------------------&gt;
<------------- Sign(K_cps, Blinded(K_temp)) &lt;------------- 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)) ---&gt;
]]></artwork> </artwork>
</figure> <t indent="0" pn="section-7.5-3">At an initial time when no call is yet
<t> in progress, a potential client 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 indent="0" pn="section-7.5-4">
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 indent="0" pn="section-7.5-5">
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 indent="0" pn="section-7.5-6">
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" sectionFormat="of" derivedContent="RFC82
vily redirected call is still alerting. 24"/> (i.e., sixty seconds)
</t><t> unless some local policy for a CPS deployment requires a longer or shorter inter
An alternative potential approach to blind signatures would be the use of oblivi val.
ous pseudorandom functions (VOPRFs, per <xref target="I-D.privacy-pass"/>), whic Any reduction in this window makes substitution attacks
h move prove faster. (see <xref target="sub" format="default" sectionFormat="of" derivedContent="Sect
</t> ion 7.4"/>) harder to mount,
</section> but making the window too small might conceivably age PASSporTs out
while a heavily redirected call is still alerting.
</t>
<t indent="0" pn="section-7.5-7">
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" sectionFormat="of" derivedConte
nt="PRIVACY-PASS"/>), which may prove faster.
</t>
</section>
</section> </section>
<section anchor="u8224" numbered="true" toc="include" removeInRFC="false" pn
<section anchor="u8224" title="Authentication and Verification Service Be ="section-8">
havior for Out-of-Band"> <name slugifiedName="name-authentication-and-verifica">Authentication and
<t> Verification Service Behavior for Out-of-Band</name>
<xref target="RFC8224"/> defines an authentication service and a verifica <t indent="0" pn="section-8-1">
tion service as functions that act in the context of SIP requests and responses. <xref target="RFC8224" format="default" sectionFormat="of" derivedContent="RFC82
This specification thus provides a more generic description of authentication s 24"/> defines an authentication service and a verification service as functions
ervice and verification service behavior that might or might not involve any SIP that act in the context of SIP requests and responses. This specification thus p
transactions, but depends only on placing a request for communications from rovides a more generic description of authentication service and verification se
an originating identity to one or more destination identities. rvice behavior that might or might not involve any SIP transactions, but depends
</t> only on placing a request for communications from
<section anchor="as" title="Authentication Service (AS)"> an originating identity to one or more destination identities.
<t> </t>
Out-of-band authentication services perform steps similar to those define <section anchor="as" numbered="true" toc="include" removeInRFC="false" pn=
d in <xref target="RFC8224"/> with some exceptions: "section-8.1">
</t><t> <name slugifiedName="name-authentication-service-as">Authentication Serv
Step 1: The authentication service MUST determine whether it is ice (AS)</name>
<t indent="0" pn="section-8.1-1">
Out-of-band authentication services perform steps similar to those defined in <x
ref target="RFC8224" format="default" sectionFormat="of" derivedContent="RFC8224
"/> with some exceptions:
</t>
<t indent="0" pn="section-8.1-2">
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" sectionFormat="of" de
</t><t> rivedContent="RFC8225">STIR certificate</xref>.
Step 2: The authentication service MUST determine that the originator of </t>
communications can claim the originating identity. This is a policy <t indent="0" pn="section-8.1-3">
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" indent="0" pn="section-8.1-4">
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" sectionFormat="of" derivedContent="Section 11"/>).
hanism (see <xref target="cps"/>) used to find the appropriate It <bcp14>MUST</bcp14> also discover (see <xref target="cps" format="default" se
CPS will also find the proper key server for the public key of the destin ctionFormat="of" derivedContent="Section 10"/>)
ation. In some cases, a destination may have multiple public encryption keys ass the CPS associated with the destination. The authentication service
ociated with it. In that case, the authentication service MUST collect all of th may already have the encryption key and destination CPS cached, or may need
ose keys. to query a service to acquire the key. Note that per <xref target="rate-control"
</t><t> format="default" sectionFormat="of" derivedContent="Section 7.5"/>,
Step 4: The authentication service MUST create the PASSporT object. This the authentication service may also need to acquire a token for PASSporT
includes acquiring the system time to populate the "iat" claim, and populating t storage from the CPS upon CPS discovery. It is anticipated that the discovery me
he "orig" and "dest" claims as chanism
described in <xref target="RFC8225"/>. The authentication service MUST th (see <xref target="cps" format="default" sectionFormat="of" derivedContent="Sect
en encrypt the PASSporT. If in Step 3 the authentication service discovered mult ion 10"/>) used to find the appropriate
iple public keys for the destination, it CPS will also find the proper key server for the public key of the destination.
MUST create one encrypted copy for each public key it discovered. In some cases, a destination may have multiple public encryption keys associated
</t><t> with it.
Finally, the authentication service stores the encrypted PASSporT(s) at t In that case, the authentication service <bcp14>MUST</bcp14> collect all of thos
he CPS discovered in Step 3. Only after that is completed should any call be ini e keys.
tiated. Note that a call might be initiated over SIP, and the authentication </t>
service would place the same PASSporT in the Identity header field value <t indent="0" pn="section-8.1-5">
of the SIP request - though SIP would carry a cleartext version rather than an e Step 4: The authentication service <bcp14>MUST</bcp14> create the PASSporT objec
ncrypted version sent to the CPS. In that case, out-of-band would serve as a fal t. This includes acquiring the system time to populate the "iat" claim, and popu
lback mechanism in case the request was not conveyed over SIP end-to-end. Also, lating the "orig" and "dest" claims as
note that the authentication service MAY described in <xref target="RFC8225" format="default" sectionFormat="of" derivedC
use a compact form of the PASSporT for a SIP request, whereas the version ontent="RFC8225"/>. The authentication service <bcp14>MUST</bcp14> then encrypt
stored at the CPS MUST always be a full form PASSporT. the PASSporT. If in Step 3 the authentication service discovered multiple public
</t> keys for the destination, it
</section> <bcp14>MUST</bcp14> create one encrypted copy for each public key it dis
<section anchor="vs" title="Verification Service (VS)"> covered.
<t> </t>
When a call arrives, an out-of-band verification service performs steps s <t indent="0" pn="section-8.1-6">
imilar to those defined in <xref target="RFC8224"/> with some exceptions: Finally, the authentication service stores the encrypted PASSporT(s) at the CPS
</t><t> discovered in Step 3. Only after that is completed should any call be initiated.
Step 1: The verification service contacts the CPS and requests all curren Note that a call might be initiated over SIP, and the authentication
t PASSporTs for its destination number; or alternatively it may receive PASSporT service would place the same PASSporT in the Identity header field value of the
s through a push interface from the CPS in some deployments. The verification se SIP request --
rvice MUST then decrypt all PASSporTs using its private key. Some PASSporTs may though SIP would carry a cleartext version rather than an encrypted version
not be decryptable for any number of reasons: they may be intended for a differe sent to the CPS. In that case, out-of-band would serve as a fallback mechanism
nt verification service, or they may be "dummy" values inserted by the CPS for p if the request was not conveyed over SIP end-to-end. Also, note that the
rivacy purposes. The next few steps will narrow down the set of PASSporTs that t authentication service <bcp14>MAY</bcp14> use a compact form of the PASSporT
he verification service will examine from that initial decryptable set. for a SIP request, whereas the version stored at the CPS <bcp14>MUST</bcp14>
</t><t> always be a full-form PASSporT.
Step 2: The verification service MUST determine if any "ppt" extensions i </t>
n the PASSporTs are unsupported. It takes only the set of supported PASSporTs an </section>
d applies the next step to them. <section anchor="vs" numbered="true" toc="include" removeInRFC="false" pn=
</t><t> "section-8.2">
Step 3: The verification service MUST determine if there is an overlap be <name slugifiedName="name-verification-service-vs">Verification Service
tween the calling party number presented in call signaling and the "orig" field (VS)</name>
of any decrypted PASSporTs. It takes the set of matching PASSporTs and applies t <t indent="0" pn="section-8.2-1">
he 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" sectionFormat="of" d
Step 4: The verification service MUST determine if the credentials that s erivedContent="RFC8224"/> with some exceptions:
igned each PASSporT are valid, and if the verification service trusts the CA tha </t>
t issued the credentials. It takes the set <t anchor="vs-step1" indent="0" pn="section-8.2-2">
of trusted PASSporTs to the next step. 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 5: The verification service MUST check the freshness of the "iat" cl gh a push interface from the CPS in some deployments. The verification service <
aim of each PASSporT. The exact interval of time that determines freshness is le bcp14>MUST</bcp14> then decrypt all PASSporTs using its private key. Some PASSpo
ft to local policy. It takes the set of fresh PASSporTs to the next step. rTs may not be decryptable for any number of reasons: they may be intended for a
</t><t> different verification service, or they may be "dummy" values inserted by the C
Step 6: The verification service MUST check the validity of the signature PS for privacy purposes. The next few steps will narrow down the set of PASSporT
over each PASSporT, as described in <xref target="RFC8225"/>. s that the verification service will examine from that initial decryptable set.
</t><t> </t>
Finally, the verification service will end up with one or more valid PASS <t indent="0" pn="section-8.2-3">
porTs corresponding to the call it has received. In keeping with baseline STIR, Step 2: The verification service <bcp14>MUST</bcp14> determine if any "ppt" exte
this document does not dictate any particular treatment of calls that have valid nsions in the PASSporTs are unsupported. It takes only the set of supported PASS
PASSporTs associated with them; the handling of the call porTs and applies the next step to them.
</t>
<t indent="0" pn="section-8.2-4">
Step 3: The verification service <bcp14>MUST</bcp14> determine if there is an ov
erlap between the calling party number presented in call signaling and the "orig
" field of any decrypted PASSporTs. It takes the set of matching PASSporTs and a
pplies the next step to them.
</t>
<t indent="0" pn="section-8.2-5">
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 indent="0" pn="section-8.2-6">
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 indent="0" pn="section-8.2-7">
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" sectionFormat="of" derivedContent="RFC8225"/>.
</t>
<t indent="0" pn="section-8.2-8">
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="include" removeInRFC="false"
<t> pn="section-8.3">
The STIR out-of-band mechanism also supports the presence of gateway plac <name slugifiedName="name-gateway-placement-services">Gateway Placement
ement services, which do not create PASSporTs themselves, but instead take PASSp Services</name>
orTs out of signaling protocols and store them at a CPS before gatewaying to a p <t indent="0" pn="section-8.3-1">
rotocol that cannot carry PASSporTs itself. For example, a SIP gateway that send The STIR out-of-band mechanism also supports the presence of gateway placement s
s calls to the PSTN could receive a call with an Identity header field, extract ervices, which do not create PASSporTs themselves, but instead take PASSporTs ou
a PASSporT from the Identity header field, and store that PASSporT at a CPS. t of signaling protocols and store them at a CPS before gatewaying to a protocol
</t><t> that cannot carry PASSporTs itself. For example, a SIP gateway that sends calls
To place a PASSporT at a CPS, a gateway MUST perform Step 3 of <xref targ to the PSTN could receive a call with an Identity header field, extract a PASSp
et="as"/> above: that is, it must discover the CPS and public key associated wit orT from the Identity header field, and store that PASSporT at a CPS.
h the destination of the call, and may need to acquire a PASSporT storage token </t>
(see <xref target="stor"/>). Per Step 3 of <xref target="as"/> this may entail d <t indent="0" pn="section-8.3-2">
iscovering several keys. The gateway then collects the in-band PASSporT(s) from To place a PASSporT at a CPS, a gateway <bcp14>MUST</bcp14> perform
the in-band signaling, encrypts the PASSporT(s), and stores them at the CPS. <xref target="as-step3" format="none" sectionFormat="of" derivedContent="">Step
</t><t> 3</xref> of <xref target="as" format="default" sectionFormat="of" derivedContent
A similar service could be performed by a gateway that retrieves PASSporT ="Section 8.1"/> above:
s from a CPS and inserts them into signaling protocols that support carrying PAS that is, it must discover the CPS and public key associated with the
SporTS in-band. This behavior may be defined by future specifications. destination of the call, and may need to acquire a PASSporT storage token
</t> (see <xref target="stor" format="default" sectionFormat="of" derivedContent="Sec
</section> tion 6.1"/>). Per <xref target="as-step3" format="none" sectionFormat="of" deriv
</section> edContent="">Step 3</xref>
of <xref target="as" format="default" sectionFormat="of" derivedContent="Section
<section anchor="web" title="Example HTTPS Interface to the CPS"> 8.1"/>, this may entail discovering several keys.
<t> The gateway then collects the in-band PASSporT(s) from the in-band signaling,
As a rough example, we show a Call Placement Service implementation here encrypts the PASSporT(s), and stores them at the CPS.
which uses a REST API to store and retrieve objects at the CPS. The calling part </t>
y stores the PASSporT at the CPS prior to initiating the call; the <t indent="0" pn="section-8.3-3">
PASSporT is stored at a location at the CPS that corresponds to the calle A similar service could be performed by a gateway that retrieves PASSporTs from
d number. Note that it is possible for multiple parties to be calling a number a a CPS and inserts them into signaling protocols that support carrying PASSporTs
t the same time, and that for called in-band. This behavior may be defined by future specifications.
numbers such as large call centers, many PASSporTs could legitimately be </t>
stored simultaneously, and it might prove difficult to correlate these with inco </section>
ming calls. </section>
</t> <section anchor="web" numbered="true" toc="include" removeInRFC="false" pn="
<t> section-9">
Assume that an authentication service has created the following PASSporT <name slugifiedName="name-example-https-interface-to-">Example HTTPS Inter
for a call to the telephone number 2.222.555.2222 (note that these are dummy val face to the CPS</name>
ues): <t indent="0" pn="section-9-1">
</t> As a rough example, we show a CPS implementation here that uses a
<figure> Representational State Transfer (REST) API <xref target="REST" format="default"
<artwork><![CDATA[ sectionFormat="of" derivedContent="REST"/> to store and retrieve objects at the
CPS.
The calling party stores the PASSporT at the CPS prior to initiating the call; t
he
PASSporT is stored at a location at the CPS that corresponds to the called numbe
r.
Note that it is possible for multiple parties to be calling a number at the same
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 indent="0" pn="section-9-2">
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="" pn="section-9-3">
eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9 eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9
jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJkZXN0Ijp7InRuIjpbI jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJkZXN0Ijp7InRuIjpbI
jIyMjI1NTUyMjIyIl19LCJpYXQiOiIxNTgzMjUxODEwIiwib3JpZyI6eyJ0biI6 jIyMjI1NTUyMjIyIl19LCJpYXQiOiIxNTgzMjUxODEwIiwib3JpZyI6eyJ0biI6
IjExMTE1NTUxMTExIn19.pnij4IlLHoR4vxID0u3CT1e9Hq4xLngZUTv45Vbxmd IjExMTE1NTUxMTExIn19.pnij4IlLHoR4vxID0u3CT1e9Hq4xLngZUTv45Vbxmd
3IVyZug4KOSa378yfP4x6twY0KTdiDypsereS438ZHaQ 3IVyZug4KOSa378yfP4x6twY0KTdiDypsereS438ZHaQ
]]></artwork> </artwork>
</figure> <t indent="0" pn="section-9-4">
<t> Through some discovery mechanism (see <xref target="cps" format="default" sectio
Through some discovery mechanism (see <xref target="cps"/>), the authenti nFormat="of" derivedContent="Section 10"/>), the authentication service discover
cation service discovers the network location of a web service that acts as the s the network location of a web service that acts as the CPS for 2.222.555.2222.
CPS for 2.222.555.2222. Through the same mechanism, we will say that it has also Through the same mechanism, we will say that it has also discovered one public
discovered one public encryption key for that destination. It uses that encrypt encryption key for that destination. It uses that encryption key to encrypt the
ion key to encrypt the PASSporT, resulting in the encrypted PASSporT: PASSporT, resulting in the encrypted PASSporT:
</t> </t>
<figure> <artwork name="" type="" align="left" alt="" pn="section-9-5">
<artwork><![CDATA[
rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w
MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm
nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV
wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1 wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1
IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j
]]></artwork> </artwork>
</figure> <t indent="0" pn="section-9-6">
<t> Having concluded the numbered steps in <xref target="as" format="default" sectio
Having concluded the numbered steps in <xref target="as"/>, including ac nFormat="of" derivedContent="Section 8.1"/>, including acquiring any token (per
quiring any token (per <xref target="stor"/>) needed to store the PASSporT at th <xref target="stor" format="default" sectionFormat="of" derivedContent="Section
e CPS, the authentication service then stores the encrypted PASSporT: 6.1"/>) needed to store the PASSporT at the CPS, the authentication service then
</t> stores the encrypted PASSporT:
<figure> </t>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt="" pn="section-9-7">
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 indent="0" pn="section-9-8">
<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="" pn="section-9-9">
</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 indent="0" pn="section-9-10">
<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="" pn="section-9-11">
</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&gt; Link: <https://cps.example.com/cps/2.222.555.2222/ppts&gt;
rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w
MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm
nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV
wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1 wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1
IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j
]]></artwork> </artwork>
</figure> <t indent="0" pn="section-9-12">
<t> That concludes <xref target="vs-step1" format="none" sectionFormat="of" derived
That concludes Step 1 of <xref target="vs"/>; the verification service t Content="">Step 1</xref> of <xref target="vs" format="default" sectionFormat="of
hen goes on to the next step, processing that PASSporT through its various check " derivedContent="Section 8.2"/>; the verification service then goes on to the n
s. A complete protocol description for CPS interactions is left to future work. ext step, processing that PASSporT through its various checks. A complete protoc
</t> ol description for CPS interactions is left to future work.
</section> </t>
</section>
<section anchor="cps" title="CPS Discovery"> <section anchor="cps" numbered="true" toc="include" removeInRFC="false" pn="
<t> section-10">
In order for the two ends of the out-of-band dataflow to coordinate, they <name slugifiedName="name-cps-discovery">CPS Discovery</name>
must agree on a way to discover a CPS and retrieve PASSporT objects from it <t indent="0" pn="section-10-1">
based solely on the rendezvous information available: the calling party n In order for the two ends of the out-of-band dataflow to coordinate, they must a
umber and the called number. Because the storage of PASSporTs in this architectu gree on a way to discover a CPS and retrieve PASSporT objects from it
re is indexed based solely on the rendezvous information available: the calling party number a
by the called party number, it makes sense to discover a CPS based on the nd the called number. Because the storage of PASSporTs in this architecture is i
called party number as well. ndexed
There are a number of potential service discovery mechanisms that could b by the called party number, it makes sense to discover a CPS based on the called
e used for party number as well.
this purpose. The means of service discovery may vary by use case. There are a number of potential service discovery mechanisms that could be used
</t><t> for
Although the discussion above is written largely in terms of a single CP this purpose. The means of service discovery may vary by use case.
S, having a significant fraction of all telephone calls result in storing and re </t>
trieving PASSporTs at a single monolithic CPS <t indent="0" pn="section-10-2">
Although the discussion above is written largely in terms of a single CPS, havi
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 indent="0" pn="section-10-3">
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" bare="false" indent="3" pn="section-10-4
tion can simply ">
<li pn="section-10-4.1">
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 pn="section-10-4.2">
"/>), 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" sectionFormat="of" derivedContent="Section 11"/>),
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" sectionFormat="of" deriv
edContent="RFC8226"/> 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 pn="section-10-4.3">
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" sectionFormat="of" derivedContent="RFC61
easily reused today to help the endpoints discover a common CPS. Other protocols 16">ENUM</xref> is commonly implemented,
associated with queries for though no "golden root" central ENUM administration exists that could be easily
telephone numbers, such as the <xref target="I-D.ietf-modern-teri">TeRI</ reused today to help the endpoints discover a common CPS. Other protocols associ
xref> protocol, could also serve for this application. ated
</t><t> with queries for telephone numbers, such as the
Another possibility is to use a single distributed service for this funct <xref target="I-D.ietf-modern-teri" format="default" sectionFormat="of" derivedC
ion. <xref target="I-D.jennings-vipr-overview">VIPR</xref> proposed a ontent="MODERN-TERI">Telephone-Related Information (TeRI) protocol</xref>,
<xref target="RFC6940">RELOAD</xref> usage for telephone numbers to help could also serve for this application.
direct calls to enterprises on the Internet. It would be possible to describe a </li>
similar RELOAD usage <li pn="section-10-4.4">
to identify the CPS where calls for a particular telephone number should Another possibility is to use a single distributed service for this function.
be stored. One advantage that the STIR architecture has over VIPR is that it ass <xref target="I-D.jennings-vipr-overview" format="default" sectionFormat="of" de
umes a credential system rivedContent="VIPR-OVERVIEW">Verification Involving PSTN Reachability (VIPR)</xr
that proves authority over telephone numbers; those credentials could be ef> proposed a
used to determine whether or not a CPS could legitimately claim to be the proper <xref target="RFC6940" format="default" sectionFormat="of" derivedContent="RFC69
store for a given telephone 40">REsource LOcation And Discovery (RELOAD)</xref> usage for telephone numbers
number. to help direct calls to enterprises on the Internet. It would be possible to des
</t></list></t><t> cribe a similar RELOAD usage
This document does not prescribe any single way to do service discovery f to identify the CPS where calls for a particular telephone number should be stor
or a CPS; it is envisioned that initial deployments will provision the location ed.
of the CPS at the Authentication Service and Verification Service. One advantage that the STIR architecture has over VIPR is that it assumes a cred
</t> ential system
</section> that proves authority over telephone numbers; those credentials could be used to
determine
<section anchor="lookup" title="Encryption Key Lookup"> whether or not a CPS could legitimately claim to be the proper store for a given
<t> telephone
In order to encrypt a PASSporT (see <xref target="stor"/>), the caller needs number.
access to the callee's </li>
public encryption key. Note that because STIR uses ECDSA for signing PASSporT </ul>
s, the public key used to <t indent="0" pn="section-10-5">
verify PASSporTs is not suitable for this function, and thus the encryption k This document does not prescribe any single way to do service discovery for a CP
ey must be discovered separately. This requires some sort S;
it is envisioned that initial deployments will provision the location of the CPS
at the authentication service and verification service.
</t>
</section>
<section anchor="lookup" numbered="true" toc="include" removeInRFC="false" p
n="section-11">
<name slugifiedName="name-encryption-key-lookup">Encryption Key Lookup</na
me>
<t indent="0" pn="section-11-1">
In order to encrypt a PASSporT (see <xref target="stor" format="default" sect
ionFormat="of" derivedContent="Section 6.1"/>), the caller needs access to the c
allee'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 indent="0" pn="section-11-2">
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 indent="0" pn="section-11-3">
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" s
ubcert</xref> of the STIR credential. That subcert could be looked up along with ectionFormat="of" derivedContent="RFC7748">Elliptic Curve Diffie-Hellman (ECDH)<
the STIR credential of the called party. Further details of this subcert, and t /xref>
he exact lookup mechanism involved, are deferred for future protocol work. public-private key pair might be generated for a
</t><t> <xref target="I-D.ietf-tls-subcerts" format="default" sectionFormat="of" derived
Content="TLS-SUBCERTS">subcert</xref> of the STIR 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 indent="0" pn="section-11-4">
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" bare="false" indent="3" pn="section-11-5
">
<li pn="section-11-5.1">
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 pn="section-11-5.2">
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 indent="0" pn="section-11-6">
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" sectionFormat="of" derivedContent="RF
C6960">Online Certificate Status Protocol (OCSP)</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 indent="0" pn="section-11-7">
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="include" removeInRFC="false" pn=
<section anchor="IANA" title="IANA Considerations"> "section-12">
<t>This memo includes no request to IANA.</t> <name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t indent="0" pn="section-12-1">This document has no IANA actions.</t>
</section> </section>
<section anchor="priv" numbered="true" toc="include" removeInRFC="false" pn=
<section anchor="priv" title="Privacy Considerations"> "section-13">
<t> <name slugifiedName="name-privacy-considerations">Privacy Considerations</
Delivering PASSporTs out-of-band offers a different set of privacy propertie name>
s than traditional in-band STIR. In-band operations convey <t indent="0" pn="section-13-1">
PASSporTs as headers in SIP messages in cleartext, which any forwarding inte Delivering PASSporTs out-of-band offers a different set of privacy propertie
rmediaries can potentially inspect. By contrast, out-of-band s
STIR stores these PASSporTs at a service after encrypting them as described than traditional in-band STIR. In-band operations convey
in <xref target="authz"/>, effectively creating a path PASSporTs as headers in SIP messages in cleartext, which any
between the authentication and verification service in which the CPS is the forwarding intermediaries can potentially inspect. By contrast, out-of-band
sole intermediary, but the CPS cannot read the PASSporTs. STIR stores these PASSporTs at a service after encrypting them
as described in <xref target="authz" format="default" sectionFormat="of" derived
Content="Section 6"/>, effectively creating a 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 indent="0" pn="section-13-2">
. 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" sectionFormat="of" derivedContent="RFC8224"/>,
/>) 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" sectionFormat
to a lesser extent any discovery services, thus create potential opportunities f ="of" derivedContent="Section 9"/> serves as an 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" sectionFormat="of" derivedConten
The process of storing and retrieving PASSporTs at a CPS can itself reveal i t="Section 10"/>) and/or encryption keys
nformation about calls being placed. The mechanism takes (<xref target="lookup" format="default" sectionFormat="of" derivedContent="Secti
care not to require that the AS authenticate itself to the CPS, relying inst on 11"/>). Even with encrypted PASSporTs,
ead on a blind signature mechanism for flood control prevention. the network interactions by which the AS and VS interact with the CPS, and
<xref target="sub"/> to a lesser extent any discovery services, thus create potential opportunities
discusses the practice of storing "dummy" PASSporTs at random intervals to t for data leakage about calling and called parties.
hwart traffic analysis, and as <xref target="vs"/> notes, a CPS is required to </t>
return a dummy PASSporT even if there is no PASSporT indexed for that callin <t indent="0" pn="section-13-3">
g number, which similarly enables the retrieval side to The process of storing and retrieving PASSporTs at a CPS can itself
randomly request PASSporTs when there are no calls in progress. These measur reveal information about calls being placed. The mechanism takes
es can help to mitigiate information disclosure in the system. In implementation care not to require that the AS authenticate itself to the CPS,
s that require service discovery (see <xref target="cps"/>), perhaps through key relying instead on a blind signature mechanism for flood control prevention.
discovery (<xref target="lookup"/>), similar measures could be used to make sur <xref target="sub" format="default" sectionFormat="of" derivedContent="Section 7
e that service discovery does not itself disclose information about calls. .4"/>
</t><t> discusses the practice of storing "dummy" PASSporTs at random intervals
Ultimately, this document only provides a framework for future implementatio to thwart traffic analysis, and as <xref target="vs" format="default" sectionFor
n of out-of-band systems, and the privacy properties of a given implementation w mat="of" derivedContent="Section 8.2"/> notes, a CPS is required to
ill depend on architectural assumptions made in those environments. More closed return a dummy PASSporT even if there is no PASSporT indexed for
systems for intranet operations may adopt a weaker security posture but otherwis that calling number, which similarly enables the retrieval side to
e mitigate the risks of information disclosure, where more open environment will randomly request PASSporTs when there are no calls in progress.
require careful implementation of the practices described here. Note that the caller's IP address itself leaks information about the caller.
</t><t> Proxying the storage of the CPS through some third party could help prevent
For general privacy risks associated with the operations of STIR, also see t this attack. It might also be possible to use a more sophisticated system
he Privacy Considerations of <xref target="RFC8224"/>. such as Riposte <xref target="RIPOSTE" format="default" sectionFormat="of" deriv
</t> edContent="RIPOSTE"/>.
</section> These measures can help to mitigate information disclosure in the system.
In implementations that require service discovery
<section anchor="Security" title="Security Considerations"> (see <xref target="cps" format="default" sectionFormat="of" derivedContent="Sect
<t>This entire document is about security, but the detailed security ion 10"/>), perhaps through key discovery
(<xref target="lookup" format="default" sectionFormat="of" derivedContent="Secti
on 11"/>), similar measures could be used
to make sure that service discovery does not itself disclose information about c
alls.
</t>
<t indent="0" pn="section-13-4">
Ultimately, this document only provides a framework for future implementatio
n
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 indent="0" pn="section-13-5">
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" derivedLink="https://rfc-editor.org/rfc/r
fc8224#section-11" derivedContent="RFC8224"/>.
</t>
</section>
<section anchor="Security" numbered="true" toc="include" removeInRFC="false"
pn="section-14">
<name slugifiedName="name-security-considerations">Security Considerations
</name>
<t indent="0" pn="section-14-1">This entire document is about security, bu
t 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" sectionFormat="of" derivedContent="
<t>Although there are considerable security challenges associated with wid 7.3"/> and <xref target="sub" format="counter" sectionFormat="of" derivedContent
espread deployment of a public CPS, those must be weighed against the potential ="7.4"/>,
usefulness of a service that delivers a STIR assurance without requiring the pas along proposed solutions for problems like denial-of-service attacks or traffic
sage of end-to-end SIP. Ultimately, the security properties of this mechanism ar analysis against the CPS.</t>
e at least comparable to in-band <t indent="0" pn="section-14-2">Although there are considerable security c
STIR: the substitution attack documented in <xref target="sub"/> could hallenges associated with
be implemented by any in-band SIP intermediary or eavesdropper who happened to s widespread deployment of a public CPS, those must be weighed against the
ee the PASSporT in transit, say, and launch its own call with a copy of that PAS potential usefulness of a service that delivers a STIR assurance without
SporT to race against the original to the destination. requiring the passage of end-to-end SIP. Ultimately, the security properties
of this mechanism are at least comparable to in-band
STIR: the substitution attack documented in <xref target="sub" format="default
" sectionFormat="of" derivedContent="Section 7.4"/>
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 --> <displayreference target="I-D.ietf-stir-passport-divert" to="PASSPORT-DIVERT
"/>
<!-- There are 2 ways to insert reference entries from the citation librarie <displayreference target="I-D.ietf-modern-teri" to="MODERN-TERI"/>
s: <displayreference target="I-D.ietf-tls-subcerts" to="TLS-SUBCERTS"/>
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here ( <displayreference target="I-D.privacy-pass" to="PRIVACY-PASS"/>
as shown) <displayreference target="I-D.jennings-vipr-overview" to="VIPR-OVERVIEW"/>
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml <references pn="section-15">
"?> here <name slugifiedName="name-informative-references">Informative References</
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.x name>
ml") <reference anchor="I-D.ietf-modern-teri" quoteTitle="true" target="https:/
/tools.ietf.org/html/draft-ietf-modern-teri-00" derivedAnchor="MODERN-TERI">
Both are cited textually in the same manner: by using xref elements. <front>
If you use the PI option, xml2rfc will, by default, try to find included fil <title>An Architecture and Information Model for Telephone-Related Inf
es in the same ormation (TeRI)</title>
directory as the including file. You can also define the XML_LIBRARY environ <author initials="J" surname="Peterson" fullname="Jon Peterson">
ment variable <organization showOnFrontPage="true"/>
with a value containing a set of directories to search. These can be either </author>
in the local <date month="July" day="2" year="2018"/>
filing system or remote ones accessed by http (http://domain/dir/... ).--> <abstract>
<t indent="0">As telephone services migrate to the Internet, Interne
<references title="Informative References"> t applications require tools to access and manage information about telephone nu
&RFC2119; mbers. This document specifies a protocol-independent framework and information
&RFC2560; model for managing service and administration data related to telephone numbers
&RFC5636; .</t>
&RFC7340; </abstract>
&RFC7258; </front>
&RFC3261; <seriesInfo name="Internet-Draft" value="draft-ietf-modern-teri-00"/>
&RFC6116; <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-iet
&RFC6940; f-modern-teri-00.txt"/>
&RFC7748; <refcontent>Work in Progress</refcontent>
&RFC8224; </reference>
&RFC8225; <reference anchor="I-D.ietf-stir-passport-divert" quoteTitle="true" target
&RFC8226; ="https://tools.ietf.org/html/draft-ietf-stir-passport-divert-09" derivedAnchor=
&RFC8174; "PASSPORT-DIVERT">
&RFC8446; <front>
&I-D.ietf-stir-passport-divert; <title>PASSporT Extension for Diverted Calls</title>
&I-D.ietf-modern-teri; <author initials="J" surname="Peterson" fullname="Jon Peterson">
&I-D.ietf-tls-subcerts; <organization showOnFrontPage="true"/>
&I-D.privacy-pass; </author>
&I-D.jennings-vipr-overview; <date month="July" day="13" year="2020"/>
<abstract>
<t indent="0">PASSporT is specified in RFC 8225 to convey cryptograp
hically-signed information about the people involved in personal communications.
This document extends PASSporT to include an indication that a call has been di
verted from its original destination to a new one. This information can greatly
improve the decisions made by verification services in call forwarding scenario
s. Also specified here is an encapsulation mechanism for nesting a PASSporT wit
hin another PASSporT that assists relying parties in some diversion scenarios.</
t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-stir-passport-divert
-09"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-iet
f-stir-passport-divert-09.txt"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="I-D.privacy-pass" quoteTitle="true" target="https://too
ls.ietf.org/html/draft-privacy-pass-00" derivedAnchor="PRIVACY-PASS">
<front>
<title>The Privacy Pass Protocol</title>
<author initials="A" surname="Davidson" fullname="Alex Davidson">
<organization showOnFrontPage="true"/>
</author>
<author initials="N" surname="Sullivan" fullname="Nick Sullivan">
<organization showOnFrontPage="true"/>
</author>
<date month="November" day="3" year="2019"/>
<abstract>
<t indent="0">This document specifies the Privacy Pass protocol for
anonymously authorizing clients with services on the Internet. Note to Readers
Source for this draft and an issue tracker can be found at https://github.com/g
rittygrease/draft-privacy-pass [1].</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-privacy-pass-00"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-pri
vacy-pass-00.txt"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="REST" quoteTitle="true" derivedAnchor="REST">
<front>
<title>Architectural Styles and the Design of Network-based Software A
rchitectures, Chapter 5: Representational State Transfer</title>
<author initials="R" surname="Fielding" fullname="Roy Fielding">
<organization showOnFrontPage="true"/>
</author>
<date year="2010"/>
</front>
<seriesInfo name="Ph.D. Dissertation," value="University of California,
Irvine"/>
<format type="pdf" target="http://www.ics.uci.edu/~fielding/pubs/dissert
ation/fielding_dissertation.pdf"/>
</reference>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc211
9" quoteTitle="true" derivedAnchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title
>
<author initials="S." surname="Bradner" fullname="S. Bradner">
<organization showOnFrontPage="true"/>
</author>
<date year="1997" month="March"/>
<abstract>
<t indent="0">In many standards track documents several words are us
ed to signify the requirements in the specification. These words are often capi
talized. This document defines these words as they should be interpreted in IETF
documents. This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for improvements.</t
>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC3261" target="https://www.rfc-editor.org/info/rfc326
1" quoteTitle="true" derivedAnchor="RFC3261">
<front>
<title>SIP: Session Initiation Protocol</title>
<author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
<organization showOnFrontPage="true"/>
</author>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Camarillo" fullname="G. Camarillo">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Johnston" fullname="A. Johnston">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Peterson" fullname="J. Peterson">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Sparks" fullname="R. Sparks">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Handley" fullname="M. Handley">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Schooler" fullname="E. Schooler">
<organization showOnFrontPage="true"/>
</author>
<date year="2002" month="June"/>
<abstract>
<t indent="0">This document describes Session Initiation Protocol (S
IP), an application-layer control (signaling) protocol for creating, modifying,
and terminating sessions with one or more participants. These sessions include
Internet telephone calls, multimedia distribution, and multimedia conferences.
[STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3261"/>
<seriesInfo name="DOI" value="10.17487/RFC3261"/>
</reference>
<reference anchor="RFC5636" target="https://www.rfc-editor.org/info/rfc563
6" quoteTitle="true" derivedAnchor="RFC5636">
<front>
<title>Traceable Anonymous Certificate</title>
<author initials="S." surname="Park" fullname="S. Park">
<organization showOnFrontPage="true"/>
</author>
<author initials="H." surname="Park" fullname="H. Park">
<organization showOnFrontPage="true"/>
</author>
<author initials="Y." surname="Won" fullname="Y. Won">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Lee" fullname="J. Lee">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Kent" fullname="S. Kent">
<organization showOnFrontPage="true"/>
</author>
<date year="2009" month="August"/>
<abstract>
<t indent="0">This document defines a practical architecture and pro
tocols for offering privacy for a user who requests and uses an X.509 certificat
e containing a pseudonym, while still retaining the ability to map such a certif
icate to the real user who requested it. The architecture is compatible with IE
TF certificate request formats such as PKCS10 (RFC 2986) and CMC (RFC 5272). Th
e architecture separates the authorities involved in issuing a certificate: one
for verifying ownership of a private key (Blind Issuer) and the other for valida
ting the contents of a certificate (Anonymity Issuer). The end entity (EE) cert
ificates issued under this model are called Traceable Anonymous Certificates (TA
Cs). This memo defines an Experimental Protocol for the Internet community.</t
>
</abstract>
</front>
<seriesInfo name="RFC" value="5636"/>
<seriesInfo name="DOI" value="10.17487/RFC5636"/>
</reference>
<reference anchor="RFC6116" target="https://www.rfc-editor.org/info/rfc611
6" quoteTitle="true" derivedAnchor="RFC6116">
<front>
<title>The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegat
ion Discovery System (DDDS) Application (ENUM)</title>
<author initials="S." surname="Bradner" fullname="S. Bradner">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Conroy" fullname="L. Conroy">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Fujiwara" fullname="K. Fujiwara">
<organization showOnFrontPage="true"/>
</author>
<date year="2011" month="March"/>
<abstract>
<t indent="0">This document discusses the use of the Domain Name Sys
tem (DNS) for storage of data associated with E.164 numbers, and for resolving t
hose numbers into URIs that can be used (for example) in telephony call setup.
This document also describes how the DNS can be used to identify the services as
sociated with an E.164 number. This document obsoletes RFC 3761. [STANDARDS-TR
ACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6116"/>
<seriesInfo name="DOI" value="10.17487/RFC6116"/>
</reference>
<reference anchor="RFC6940" target="https://www.rfc-editor.org/info/rfc694
0" quoteTitle="true" derivedAnchor="RFC6940">
<front>
<title>REsource LOcation And Discovery (RELOAD) Base Protocol</title>
<author initials="C." surname="Jennings" fullname="C. Jennings">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Lowekamp" fullname="B. Lowekamp" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Baset" fullname="S. Baset">
<organization showOnFrontPage="true"/>
</author>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
<organization showOnFrontPage="true"/>
</author>
<date year="2014" month="January"/>
<abstract>
<t indent="0">This specification defines REsource LOcation And Disco
very (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet.
A P2P signaling protocol provides its clients with an abstract storage and mess
aging service between a set of cooperating peers that form the overlay network.
RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) networ
k, but can be utilized by other applications with similar requirements by defini
ng new usages that specify the Kinds of data that need to be stored for a partic
ular application. RELOAD defines a security model based on a certificate enroll
ment service that provides unique identities. NAT traversal is a fundamental se
rvice of the protocol. RELOAD also allows access from "client" nodes that do no
t need to route traffic or store data for others.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6940"/>
<seriesInfo name="DOI" value="10.17487/RFC6940"/>
</reference>
<reference anchor="RFC6960" target="https://www.rfc-editor.org/info/rfc696
0" quoteTitle="true" derivedAnchor="RFC6960">
<front>
<title>X.509 Internet Public Key Infrastructure Online Certificate Sta
tus Protocol - OCSP</title>
<author initials="S." surname="Santesson" fullname="S. Santesson">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Myers" fullname="M. Myers">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Ankney" fullname="R. Ankney">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Malpani" fullname="A. Malpani">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Galperin" fullname="S. Galperin">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Adams" fullname="C. Adams">
<organization showOnFrontPage="true"/>
</author>
<date year="2013" month="June"/>
<abstract>
<t indent="0">This document specifies a protocol useful in determini
ng the current status of a digital certificate without requiring Certificate Rev
ocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirem
ents are specified in separate documents. This document obsoletes RFCs 2560 and
6277. It also updates RFC 5912.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6960"/>
<seriesInfo name="DOI" value="10.17487/RFC6960"/>
</reference>
<reference anchor="RFC7258" target="https://www.rfc-editor.org/info/rfc725
8" quoteTitle="true" derivedAnchor="RFC7258">
<front>
<title>Pervasive Monitoring Is an Attack</title>
<author initials="S." surname="Farrell" fullname="S. Farrell">
<organization showOnFrontPage="true"/>
</author>
<author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
<organization showOnFrontPage="true"/>
</author>
<date year="2014" month="May"/>
<abstract>
<t indent="0">Pervasive monitoring is a technical attack that should
be mitigated in the design of IETF protocols, where possible.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="188"/>
<seriesInfo name="RFC" value="7258"/>
<seriesInfo name="DOI" value="10.17487/RFC7258"/>
</reference>
<reference anchor="RFC7340" target="https://www.rfc-editor.org/info/rfc734
0" quoteTitle="true" derivedAnchor="RFC7340">
<front>
<title>Secure Telephone Identity Problem Statement and Requirements</t
itle>
<author initials="J." surname="Peterson" fullname="J. Peterson">
<organization showOnFrontPage="true"/>
</author>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
<organization showOnFrontPage="true"/>
</author>
<author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
<organization showOnFrontPage="true"/>
</author>
<date year="2014" month="September"/>
<abstract>
<t indent="0">Over the past decade, Voice over IP (VoIP) systems bas
ed on SIP have replaced many traditional telephony deployments. Interworking Vo
IP systems with the traditional telephone network has reduced the overall level
of calling party number and Caller ID assurances by granting attackers new and i
nexpensive tools to impersonate or obscure calling party numbers when orchestrat
ing bulk commercial calling schemes, hacking voicemail boxes, or even circumvent
ing multi-factor authentication systems trusted by banks. Despite previous atte
mpts to provide a secure assurance of the origin of SIP communications, we still
lack effective standards for identifying the calling party in a VoIP session.
This document examines the reasons why providing identity for telephone numbers
on the Internet has proven so difficult and shows how changes in the last decade
may provide us with new strategies for attaching a secure identity to SIP sessi
ons. It also gives high-level requirements for a solution in this space.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7340"/>
<seriesInfo name="DOI" value="10.17487/RFC7340"/>
</reference>
<reference anchor="RFC7748" target="https://www.rfc-editor.org/info/rfc774
8" quoteTitle="true" derivedAnchor="RFC7748">
<front>
<title>Elliptic Curves for Security</title>
<author initials="A." surname="Langley" fullname="A. Langley">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Hamburg" fullname="M. Hamburg">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Turner" fullname="S. Turner">
<organization showOnFrontPage="true"/>
</author>
<date year="2016" month="January"/>
<abstract>
<t indent="0">This memo specifies two elliptic curves over prime fie
lds that offer a high level of practical security in cryptographic applications,
including Transport Layer Security (TLS). These curves are intended to operate
at the ~128-bit and ~224-bit security level, respectively, and are generated de
terministically based on a list of required properties.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7748"/>
<seriesInfo name="DOI" value="10.17487/RFC7748"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc817
4" quoteTitle="true" derivedAnchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</titl
e>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="May"/>
<abstract>
<t indent="0">RFC 2119 specifies common key words that may be used i
n protocol specifications. This document aims to reduce the ambiguity by clari
fying that only UPPERCASE usage of the key words have the defined special meani
ngs.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8224" target="https://www.rfc-editor.org/info/rfc822
4" quoteTitle="true" derivedAnchor="RFC8224">
<front>
<title>Authenticated Identity Management in the Session Initiation Pro
tocol (SIP)</title>
<author initials="J." surname="Peterson" fullname="J. Peterson">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Jennings" fullname="C. Jennings">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Wendt" fullname="C. Wendt">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="February"/>
<abstract>
<t indent="0">The baseline security mechanisms in the Session Initia
tion Protocol (SIP) are inadequate for cryptographically assuring the identity o
f the end users that originate SIP requests, especially in an interdomain contex
t. This document defines a mechanism for securely identifying originators of SI
P requests. It does so by defining a SIP header field for conveying a signature
used for validating the identity and for conveying a reference to the credentia
ls of the signer.</t>
<t indent="0">This document obsoletes RFC 4474.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8224"/>
<seriesInfo name="DOI" value="10.17487/RFC8224"/>
</reference>
<reference anchor="RFC8225" target="https://www.rfc-editor.org/info/rfc822
5" quoteTitle="true" derivedAnchor="RFC8225">
<front>
<title>PASSporT: Personal Assertion Token</title>
<author initials="C." surname="Wendt" fullname="C. Wendt">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Peterson" fullname="J. Peterson">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="February"/>
<abstract>
<t indent="0">This document defines a method for creating and valida
ting a token that cryptographically verifies an originating identity or, more ge
nerally, a URI or telephone number representing the originator of personal commu
nications. The Personal Assertion Token, PASSporT, is cryptographically signed
to protect the integrity of the identity of the originator and to verify the ass
ertion of the identity information at the destination. The cryptographic signat
ure is defined with the intention that it can confidently verify the originating
persona even when the signature is sent to the destination party over an insecu
re channel. PASSporT is particularly useful for many personal-communications ap
plications over IP networks and other multi-hop interconnection scenarios where
the originating and destination parties may not have a direct trusted relationsh
ip.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8225"/>
<seriesInfo name="DOI" value="10.17487/RFC8225"/>
</reference>
<reference anchor="RFC8226" target="https://www.rfc-editor.org/info/rfc822
6" quoteTitle="true" derivedAnchor="RFC8226">
<front>
<title>Secure Telephone Identity Credentials: Certificates</title>
<author initials="J." surname="Peterson" fullname="J. Peterson">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Turner" fullname="S. Turner">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="February"/>
<abstract>
<t indent="0">In order to prevent the impersonation of telephone num
bers on the Internet, some kind of credential system needs to exist that cryptog
raphically asserts authority over telephone numbers. This document describes th
e use of certificates in establishing authority over telephone numbers, as a com
ponent of a broader architecture for managing telephone numbers as identities in
protocols like SIP.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8226"/>
<seriesInfo name="DOI" value="10.17487/RFC8226"/>
</reference>
<reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc844
6" quoteTitle="true" derivedAnchor="RFC8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="August"/>
<abstract>
<t indent="0">This document specifies version 1.3 of the Transport L
ayer Security (TLS) protocol. TLS allows client/server applications to communic
ate over the Internet in a way that is designed to prevent eavesdropping, tamper
ing, and message forgery.</t>
<t indent="0">This document updates RFCs 5705 and 6066, and obsolete
s RFCs 5077, 5246, and 6961. This document also specifies new requirements for
TLS 1.2 implementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RIPOSTE" target="https://people.csail.mit.edu/henrycg/p
ubs/oakland15riposte/" quoteTitle="true" derivedAnchor="RIPOSTE">
<front>
<title>Riposte: An Anonymous Messaging System Handling Millions of Use
rs</title>
<author initials="H" surname="Corrigan-Gibbs" fullname="Henry Corrigan
-Gibbs">
<organization showOnFrontPage="true"/>
</author>
<author initials="D" surname="Boneh" fullname="Dan Boneh">
<organization showOnFrontPage="true"/>
</author>
<author initials="D" surname="Mazières" fullname="David Mazières">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="May"/>
</front>
</reference>
<reference anchor="I-D.ietf-tls-subcerts" quoteTitle="true" target="https:
//tools.ietf.org/html/draft-ietf-tls-subcerts-10" derivedAnchor="TLS-SUBCERTS">
<front>
<title>Delegated Credentials for TLS</title>
<author initials="R" surname="Barnes" fullname="Richard Barnes">
<organization showOnFrontPage="true"/>
</author>
<author initials="S" surname="Iyengar" fullname="Subodh Iyengar">
<organization showOnFrontPage="true"/>
</author>
<author initials="N" surname="Sullivan" fullname="Nick Sullivan">
<organization showOnFrontPage="true"/>
</author>
<author initials="E" surname="Rescorla" fullname="Eric Rescorla">
<organization showOnFrontPage="true"/>
</author>
<date month="January" day="24" year="2021"/>
<abstract>
<t indent="0">The organizational separation between the operator of
a TLS endpoint and the certification authority can create limitations. For exam
ple, the lifetime of certificates, how they may be used, and the algorithms they
support are ultimately determined by the certification authority. This documen
t describes a mechanism by which operators may delegate their own credentials fo
r use in TLS, without breaking compatibility with peers that do not support this
specification.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-subcerts-10"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-iet
f-tls-subcerts-10.txt"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="I-D.jennings-vipr-overview" quoteTitle="true" target="h
ttps://tools.ietf.org/html/draft-jennings-vipr-overview-06" derivedAnchor="VIPR-
OVERVIEW">
<front>
<title>Verification Involving PSTN Reachability: Requirements and Arch
itecture Overview</title>
<author initials="M" surname="Barnes" fullname="Mary Barnes">
<organization showOnFrontPage="true"/>
</author>
<author initials="C" surname="Jennings" fullname="Cullen Jennings">
<organization showOnFrontPage="true"/>
</author>
<author initials="J" surname="Rosenberg" fullname="Jonathan Rosenberg"
>
<organization showOnFrontPage="true"/>
</author>
<author initials="M" surname="Petit-Huguenin" fullname="Marc Petit-Hug
uenin">
<organization showOnFrontPage="true"/>
</author>
<date month="December" day="9" year="2013"/>
<abstract>
<t indent="0">The Session Initiation Protocol (SIP) has seen widespr
ead deployment within individual domains, typically supporting voice and video c
ommunications. Though it was designed from the outset to support inter-domain f
ederation over the public Internet, such federation has not materialized. The p
rimary reasons for this are the complexities of inter-domain phone number routin
g and concerns over security. This document reviews this problem space, outlines
requirements, and then describes a model and technique for inter-domain federat
ion with SIP involving the Public Switched Telephone Network (PSTN), called Veri
fication Involving PSTN Reachability (VIPR). VIPR addresses the problems that h
ave prevented inter-domain federation over the Internet. It provides fully dist
ributed inter-domain routing for phone numbers, authorized mappings from phone n
umbers to domains, a new technique for automated SIP anti-spam, and privacy of n
umber ownership, all while preserving the trapezoidal model of SIP.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-jennings-vipr-overview-06
"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-jen
nings-vipr-overview-06.txt"/>
<refcontent>Work in Progress</refcontent>
</reference>
</references> </references>
<section anchor="Acknowledgments" numbered="false" toc="include" removeInRFC
="false" pn="section-appendix.a">
<name slugifiedName="name-acknowledgments">Acknowledgments</name>
<t indent="0" pn="section-appendix.a-1">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>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.b">
<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
<author fullname="Eric Rescorla" initials="E." surname="Rescorla">
<organization showOnFrontPage="true">Mozilla</organization>
<address>
<email>ekr@rtfm.com</email>
</address>
</author>
<author initials="J." surname="Peterson" fullname="Jon Peterson">
<organization abbrev="Neustar" showOnFrontPage="true">Neustar, Inc.</org
anization>
<address>
<postal>
<street>1800 Sutter St Suite 570</street>
<city>Concord</city>
<region>CA</region>
<code>94520</code>
<country>United States of America</country>
</postal>
<email>jon.peterson@team.neustar</email>
</address>
</author>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 98 change blocks. 
1126 lines changed or deleted 2095 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/