rfc8816.original.v2v3.xml   rfc8816.form.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!-- updated by Chris 03/31/20 -->
<!-- <!--
vim:et:ts=2:sw=2:spell:spelllang=en:tw=80 vim:et:ts=2:sw=2:spell:spelllang=en:tw=80
--> -->
<!-- This template is for creating an Internet Draft using xml2rfc, <!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. --> which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!--?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?-->
<!-- used by XSLT processors --> <!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), <!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. --> please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use. <!-- 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) --> (Here they are set differently than their defaults in xml2rfc v1.32) -->
<!--?rfc strict="yes" ?--> <!--?rfc strict="yes" ?-->
<!-- give errors regarding ID-nits and DTD validation --> <!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) --> <!-- control the table of contents (ToC) -->
<?rfc toc="yes"?> <!-- <?rfc toc="yes"?> -->
<!-- generate a ToC --> <!-- generate a ToC -->
<?rfc tocdepth="4"?> <!-- <?rfc tocdepth="4"?> -->
<!-- the number of levels of subsections in ToC. default: 3 --> <!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references --> <!-- control references -->
<?rfc symrefs="yes"?> <!-- <?rfc symrefs="yes"?> -->
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] --> <!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?> <!-- <?rfc sortrefs="yes" ?> -->
<!-- sort the reference entries alphabetically --> <!-- sort the reference entries alphabetically -->
<!-- control vertical white space <!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) --> (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="no" ?> <!-- <?rfc compact="no" ?> -->
<!-- do not start each main section on a new page --> <!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?> <!-- <?rfc subcompact="no" ?> -->
<!-- keep one blank line between list items --> <!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions --> <!-- end of list of popular I-D processing instructions -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-i
etf-stir-oob-07" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" ver docName="draft-ietf-stir-oob-07"
sion="3"> number="0000"
ipr="trust200902"
obsoletes=""
updates=""
submissionType="IETF"
category="info"
consensus="true"
xml:lang="en"
tocInclude="true"
tocDepth="4"
symRefs="true"
sortRefs="true"
version="3">
<!-- xml2rfc v2v3 conversion 2.41.0 --> <!-- xml2rfc v2v3 conversion 2.41.0 -->
<!-- category values: std, bcp, info, exp, and historic <!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902 , ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902 ,
or pre5378Trust200902 or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN" you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" --> they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** --> <!-- ***** FRONT MATTER ***** -->
<front> <front>
<!-- The abbreviated title is used in the page header - it is only necessary if the <!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters --> full title is longer than 39 characters -->
<title abbrev="STIR Out-of-Band">STIR Out-of-Band Architecture and Use Cases </title> <title abbrev="STIR Out-of-Band">STIR Out-of-Band Architecture and Use Cases </title>
<seriesInfo name="Internet-Draft" value="draft-ietf-stir-oob-07"/> <seriesInfo name="RFC" value="0000"/>
<author fullname="Eric Rescorla" initials="E.K." surname="Rescorla"> <author fullname="Eric Rescorla" initials="E.K." surname="Rescorla">
<organization>Mozilla</organization> <organization>Mozilla</organization>
<address> <address>
<email>ekr@rtfm.com</email> <email>ekr@rtfm.com</email>
</address> </address>
</author> </author>
<author initials="J." surname="Peterson" fullname="Jon Peterson"> <author initials="J." surname="Peterson" fullname="Jon Peterson">
<organization abbrev="Neustar">Neustar, Inc.</organization> <organization abbrev="Neustar">Neustar, Inc.</organization>
<address> <address>
<postal> <postal>
<street>1800 Sutter St Suite 570</street> <street>1800 Sutter St Suite 570</street>
<city>Concord</city> <city>Concord</city>
<region>CA</region> <region>CA</region>
<code>94520</code> <code>94520</code>
<country>US</country> <country>US</country>
</postal> </postal>
<email>jon.peterson@team.neustar</email> <email>jon.peterson@team.neustar</email>
</address> </address>
</author> </author>
<date year="2020"/> <date year="2020" month="April" />
<!-- <area> <!-- <area>
ART ART
</area>--> </area>-->
<keyword>SIP</keyword> <keyword>SIP</keyword>
<abstract> <abstract>
<t> <t>
The PASSporT format defines a token that can be carried by signaling protocols, including SIP, to cryptographically attest the identify of callers. The PASSporT format defines a token that can be carried by signaling protocols, including SIP, to cryptographically attest the identify of callers.
Not all telephone calls use Internet signaling protocols, however , and some calls use them for only part of their signaling path, or cannot relia bly deliver SIP header fields end-to-end. Not all telephone calls use Internet signaling protocols, however , and some calls use them for only part of their signaling path, or cannot relia bly deliver SIP header fields end-to-end.
This document describes use cases that require the delivery of PA SSporT objects outside of the signaling path, and defines architectures and sema ntics to provide This document describes use cases that require the delivery of PA SSporT objects outside of the signaling path, and defines architectures and sema ntics to provide
skipping to change at line 152 skipping to change at line 171
out-of-band STIR mechanism is intended to operate. It provides use case s, gives a broad description of the components and a potential solution architec ture. out-of-band STIR mechanism is intended to operate. It provides use case s, gives a broad description of the components and a potential solution architec ture.
Various environments may have their own security requirements: a public deployment of out-of-band STIR faces far greater challenges than a constr ained Various environments may have their own security requirements: a public deployment of out-of-band STIR faces far greater challenges than a constr ained
intranetwork deployment. intranetwork deployment.
To flesh out the storage and retrieval of PASSporTs in the CPS within th is To flesh out the storage and retrieval of PASSporTs in the CPS within th is
context, this document includes a strawman protocol suitable for that pu rpose. Deploying this framework in any given environment context, this document includes a strawman protocol suitable for that pu rpose. Deploying this framework in any given environment
would require additional specification outside the scope of the current document. would require additional specification outside the scope of the current document.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Terminology</name> <name>Terminology</name>
<t>TThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"OPTIONAL" in this document are to be interpreted as described in IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC81 NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
74" format="default"/> when, and only when, they appear in all RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Operating Environments</name> <name>Operating Environments</name>
<t> <t>
This section describes the environments in which the proposed out-of -band STIR This section describes the environments in which the proposed out-of -band STIR
mechanism is intended to operate. In the simplest setting, Alice is mechanism is intended to operate. In the simplest setting, Alice is
calling Bob, and her call is routed through some set of gateways and/or the P STN calling Bob, and her call is routed through some set of gateways and/or the P STN
which do not support end-to-end delivery of STIR. Both Alice which do not support end-to-end delivery of STIR. Both Alice
and Bob have smart devices which can access the Internet (perhaps enterprise devices, or even end user ones), but they do not have and Bob have smart devices which can access the Internet (perhaps enterprise devices, or even end user ones), but they do not have
a clear telephone signaling connection between them: Alice cannot inject any data into a clear telephone signaling connection between them: Alice cannot inject any data into
signaling which Bob can read, with the exception of the asserted destination and origination signaling which Bob can read, with the exception of the asserted destination and origination
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 d for coordination between 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 d for coordination between
the endpoints. the endpoints.
</t> </t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+---------+ +---------+
/ \ / \
+--- +---+ +--- +---+
+----------+ / \ +----------+ +----------+ / \ +----------+
| | | Gateways | | | | | | Gateways | | |
| Alice |<----->| and/or |<----->| Bob | | Alice |<----->| and/or |<----->| Bob |
| (caller) | | PSTN | | (callee) | | (caller) | | PSTN | | (callee) |
+----------+ \ / +----------+ +----------+ \ / +----------+
+--- +---+ +--- +---+
\ / \ /
+---------+ +---------+
]]></artwork> ]]></artwork>
<t> <t>
In a more complicated setting, Alice and/or Bob may n ot have a smart or In a more complicated setting, Alice and/or Bob may n ot have a smart or
programmable device, but instead just a traditional telephone. However, one o r both of them are behind a STIR-aware gateway that can participate in out-of-ba nd coordination, as shown below: programmable device, but instead just a traditional telephone. However, one o r both of them are behind a STIR-aware gateway that can participate in out-of-ba nd coordination, as shown below:
</t> </t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+---------+ +---------+
/ \ / \
+--- +---+ +--- +---+
+----------+ +--+ / \ +--+ +----------+ +----------+ +--+ / \ +--+ +----------+
| | | | | Gateways | | | | | | | | | | Gateways | | | | |
| Alice |<-|GW|->| and/or |<-|GW|->| Bob | | Alice |<-|GW|->| and/or |<-|GW|->| Bob |
| (caller) | | | | PSTN | | | | (callee) | | (caller) | | | | PSTN | | | | (callee) |
+----------+ +--+ \ / +--+ +----------+ +----------+ +--+ \ / +--+ +----------+
+--- +---+ +--- +---+
\ / \ /
+---------+ +---------+
]]></artwork> ]]></artwork>
<t> <t>
In such a case, Alice might have an analog (e.g., PSTN) conne ction to her gateway/ 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 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 Ol' Telephone Service (POTS) mechanisms.
</t> </t>
</section> </section>
<section anchor="data" numbered="true" toc="default"> <section anchor="data" numbered="true" toc="default">
<name>Dataflows</name> <name>Dataflows</name>
skipping to change at line 377 skipping to change at line 398
</t> </t>
</section> </section>
<section anchor="retr" numbered="true" toc="default"> <section anchor="retr" numbered="true" toc="default">
<name>Retrieval</name> <name>Retrieval</name>
<t> <t>
For retrieval of PASSporTs, this architecture assumes that clients will contact the CPS through some sort of polling or notification interface to recei ve all For retrieval of PASSporTs, this architecture assumes that clients will contact the CPS through some sort of polling or notification interface to recei ve all
current PASSporTs for calls destined to a particular telephone number, or block of numbers. current PASSporTs for calls destined to a particular telephone number, or block of numbers.
</t> </t>
<t> <t>
As PASSporTs stored at the CPS are encrypted with a key belonging to th e intended destination, the CPS can safely As PASSporTs stored at the CPS are encrypted with a key belonging to th e intended destination, the CPS can safely
allow anyone to download PASSporTs for a called number without much fea r of compromising private information about calls in progress - provided that th e CPS always returns at least one encrypted blob in response to a request, even if there was no call in progress. Otherwise, entities could poll the CPS constan tly, or eavesdrop on traffic, to learn whether or not calls were in progress. Th e CPS MUST generate at least one unique and plausible encrypted response to all retrieval requests, and these dummy encrypted PASSporTs MUST NOT be repeated for later calls. An encryption scheme needs to be carefully chosen to make messages look indistinguishable from random when encrypted, so that information about ca lled party is not discoverable from legitimate encrypted PASSporTs. allow anyone to download PASSporTs for a called number without much fea r of compromising private information about calls in progress - provided that th e CPS always returns at least one encrypted blob in response to a request, even if there was no call in progress. Otherwise, entities could poll the CPS constan tly, or eavesdrop on traffic, to learn whether or not calls were in progress. Th e CPS <bcp14>MUST</bcp14> generate at least one unique and plausible encrypted r esponse to all retrieval requests, and these dummy encrypted PASSporTs <bcp14>MU ST NOT</bcp14> be repeated for later calls. An encryption scheme needs to be car efully chosen to make messages look indistinguishable from random when encrypted , so that information about called party is not discoverable from legitimate enc rypted PASSporTs.
</t> </t>
<t> <t>
Because the entity placing a call may discover 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 th at there is no call in progress. A retriever likely will need to decrypt all PAS SporTs retrieved from the CPS, and may find only one that is valid. Because the entity placing a call may discover 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 th at there is no call in progress. A retriever likely will need to decrypt all PAS SporTs retrieved from the CPS, and may find only one that is valid.
</t> </t>
<t> <t>
In order to prevent the CPS from learning the numbers that a callee controls, ca llees might also request PASSporTs for numbers that they do not own, that they h ave 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 wil ling to sift through bulk quantities of undecryptable PASSporTs for the sake of hiding from the CPS what numbers it controls. In order to prevent the CPS from learning the numbers that a callee controls, ca llees might also request PASSporTs for numbers that they do not own, that they h ave 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 wil ling to sift through bulk quantities of undecryptable PASSporTs for the sake of hiding from the CPS what numbers it controls.
</t> </t>
<t> <t>
Note that in out-of-band call forwarding cases, special behavior is req uired to manage the relationship between PASSporTs using the diversion extension <xref target="I-D.ietf-stir-passport-divert" format="default"/>. The originatin g authentication service would encrypt the initial PASSporT with the public encr yption 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 co uld not decrypt the original PASSporT. This requires the retargeting entity to g enerate encrypted PASSporTs that show a secure chain of diversion: a retargeting storer SHOULD use the "div-o" PASSporT type, with its "opt" extension, as spec ified in <xref target="I-D.ietf-stir-passport-divert" format="default"/> in orde r to nest the original PASSporT within the encrypted diversion PASSporT. Note that in out-of-band call forwarding cases, special behavior is req uired to manage the relationship between PASSporTs using the diversion extension <xref target="I-D.ietf-stir-passport-divert" format="default"/>. The originatin g authentication service would encrypt the initial PASSporT with the public encr yption 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 co uld not decrypt the original PASSporT. This requires the retargeting entity to g enerate encrypted PASSporTs that show a secure chain of diversion: a retargeting storer <bcp14>SHOULD</bcp14> use the "div-o" PASSporT type, with its "opt" exte nsion, as specified in <xref target="I-D.ietf-stir-passport-divert" format="def ault"/> in order to nest the original PASSporT within the encrypted diversion PA SSporT.
</t> </t>
</section> </section>
</section> </section>
<section anchor="arch" numbered="true" toc="default"> <section anchor="arch" numbered="true" toc="default">
<name>Solution Architecture</name> <name>Solution Architecture</name>
<t>In this section, we discuss a high-level architecture for providing the service <t>In this section, we discuss a high-level architecture for providing the service
described in the previous sections. This discussion is deliberately described in the previous sections. This discussion is deliberately
sketchy, focusing on broad concepts and skipping over details. The sketchy, focusing on broad concepts and skipping over details. The
intent here is merely to provide an overall architecture, not an implementabl e intent here is merely to provide an overall architecture, not an implementabl e
specification. A more concrete example of how this might be specified is give n in <xref target="web" format="default"/>. specification. A more concrete example of how this might be specified is give n in <xref target="web" format="default"/>.
skipping to change at line 436 skipping to change at line 457
Call from 1.111.555.1111 ------------------------------------------> Call from 1.111.555.1111 ------------------------------------------>
<-------------- Request PASSporT(s) <-------------- Request PASSporT(s)
for 2.222.555.2222 for 2.222.555.2222
Obtain Encrypted PASSporT --------> Obtain Encrypted PASSporT -------->
(2.222.555.2222, 1.111.555.1111) (2.222.555.2222, 1.111.555.1111)
[Ring phone with verified callerid [Ring phone with verified callerid
= 1.111.555.1111] = 1.111.555.1111]
]]></artwork> ]]></artwork>
<t> <t>
When Alice wishes to make a call to Bob, she contacts the CPS and When Alice wishes to make a call to Bob, she contacts the CPS and
stores an encrypted PASSporT on stores an encrypted PASSporT on
the CPS indexed under Bob's number. The CPS then awaits retrievals for the CPS indexed under Bob's number. The CPS then awaits retrievals for
that number. that number.
</t> </t>
<t> <t>
When Alice places the call, Bob's phone would usually ring and display When Alice places the call, Bob's phone would usually ring and display
Alice's number (+1.111.555.1111), which is informed by the 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 he IAM). Instead, PSTN mechanisms for relaying a calling party number (e.g., the CIN field of t he IAM). Instead,
skipping to change at line 482 skipping to change at line 503
</li> </li>
</ol> </ol>
<t> <t>
If an attacker can inject fake PASSporTs into the CPS or in the If an attacker can inject fake PASSporTs into the CPS or in the
communication from the CPS to the callee, he can mount either attack. communication from the CPS to the callee, he can mount either attack.
As PASSporTs should be 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" format="default"/>), this should not arise in ordin ary operations. Any attacker who is aware of calls in progress can attempt t o mount a race to subtitute themselves (see <xref target="phone" format="default"/>), this should not arise in ordin ary operations. Any attacker who is aware of calls in progress can attempt t o mount a race to subtitute themselves
as described in <xref target="sub" format="default"/>. For privacy and robust ness reasons, as described in <xref target="sub" format="default"/>. For privacy and robust ness reasons,
using <xref target="RFC8446" format="default">TLS</xref> on the originating s ide when storing the PASSporT at the CPS is RECOMMENDED. using <xref target="RFC8446" format="default">TLS</xref> on the originating s ide when storing the PASSporT at the CPS is <bcp14>RECOMMENDED</bcp14>.
</t> </t>
<t> <t>
The entire system depends on the security of the credential The entire system depends on the security of the credential
infrastructure. If the authentication credentials for a given number infrastructure. If the authentication credentials for a given number
are compromised, then an attacker can impersonate calls from that are compromised, then an attacker can impersonate calls from that
number. However, that is no different from in-band <xref target="RFC8224" for mat="default"/> STIR. number. However, that is no different from in-band <xref target="RFC8224" for mat="default"/> STIR.
</t> </t>
<t> <t>
A secondary attack we must also prevent is denial-of-service against the CPS, which requires some form of rate control solution that will not degrade the privacy properties of the architecture. A secondary attack we must also prevent is denial-of-service against the CPS, which requires some form of rate control solution that will not degrade the privacy properties of the architecture.
</t> </t>
skipping to change at line 523 skipping to change at line 544
Call from CS ------------------------> X Call from CS ------------------------> X
<-- Retrieve PASSporT <-- Retrieve PASSporT
for CS:Bob for CS:Bob
PASSporT for CS:Bob ------------------------> PASSporT for CS:Bob ------------------------>
[Ring phone with callerid = [Ring phone with callerid =
111.555.1111] 111.555.1111]
]]></artwork> ]]></artwork>
<t> <t>
In order to mount this attack, the attacker contacts the Callbac k In order to mount this attack, the attacker contacts the Callbac k
Service (CS) and provides it with Bob's number. This causes the CS Service (CS) and provides it with Bob's number. This causes the CS
to initiate a call to Bob. As before, the CS contacts the CPS to to initiate a call to Bob. As before, the CS contacts the CPS to
insert an appropriate PASSporT and then initiates a call to Bob. Because insert an appropriate PASSporT and then initiates a call to Bob. Because
it is a valid CS injecting the PASSporT, none of the security checks it is a valid CS injecting the PASSporT, none of the security checks
mentioned above help. However, the attacker simultaneously initiates mentioned above help. However, the attacker simultaneously initiates
a call to Bob using forged caller-id information corresponding to the a call to Bob using forged caller-id information corresponding to the
CS. If he wins the race with the CS, then Bob's phone will attempt CS. If he wins the race with the CS, then Bob's phone will attempt
to verify the attacker's call (and succeed since they are to verify the attacker's call (and succeed since they are
skipping to change at line 574 skipping to change at line 595
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
Sender CPS Sender CPS
Authenticate to CPS ---------------------> Authenticate to CPS --------------------->
Blinded(K_temp) -------------------------> Blinded(K_temp) ------------------------->
<------------- Sign(K_cps, Blinded(K_temp)) <------------- Sign(K_cps, Blinded(K_temp))
[Disconnect] [Disconnect]
Sign(K_cps, K_temp) Sign(K_cps, K_temp)
Sign(K_temp, E(K_receiver, PASSporT)) ---> Sign(K_temp, E(K_receiver, PASSporT)) --->
]]></artwork> ]]></artwork>
<t> <t>
At an initial time when no call is yet 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 gets a signature on K_temp from the CPS.
</t> </t>
<t> <t>
Then later, when a client wants to store a PASSporT, it connects Then later, when a client wants to store a PASSporT, it connects
to the CPS anonymously (preferably over a network connection that cannot be corr elated with the token acquisition) and to the CPS anonymously (preferably over a network connection that cannot be corr elated with the token acquisition) and
sends both the signed K_temp and its own signature over the sends both the signed K_temp and its own signature over the
encrypted PASSporT. The CPS verifies both signatures and if they encrypted PASSporT. The CPS verifies both signatures and if they
verify, stores the encrypted passport (discarding the signatures). verify, stores the encrypted passport (discarding the signatures).
</t> </t>
<t> <t>
This design lets the CPS rate limit how many PASSporTs a given This design lets the CPS rate limit how many PASSporTs a given
sender can store just by counting how many times K_temp appears; perhaps CPS pol icy might reject storage attempts and require acquisition of a new K_temp after storing more than a certain number of PASSporTs indexed under the same destinati on number in a short interval. This does not of course allow the CPS to tell whe n bogus data is being provisioned by an attacker, sender can store just by counting how many times K_temp appears; perhaps CPS pol icy might reject storage attempts and require acquisition of a new K_temp after storing more than a certain number of PASSporTs indexed under the same destinati on number in a short interval. This does not of course allow the CPS to tell whe n bogus data is being provisioned by an attacker,
simply the rate at which data is being provisioned. Potentially, feedback mechan isms could be developed that would allow the called parties to tell the CPS when they are receiving unusual or bogus simply the rate at which data is being provisioned. Potentially, feedback mechan isms 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> <t>
This architecture also assumes that the CPS will age out PASSporTs. A C PS SHOULD NOT keep any stored PASSporT for no longer than a value that might be selected for the verification service policy for freshness of the "iat" value as described in <xref target="RFC8224" format="default"/> (i.e. sixty seconds). An y reduction in this window makes substitution attacks (see <xref target="sub" fo rmat="default"/>) harder to mount, but making the window too small might conceiv ably age PASSporTs out while a heavily redirected call is still alerting. This architecture also assumes that the CPS will age out PASSporTs. A C PS <bcp14>SHOULD NOT</bcp14> keep any stored PASSporT for no longer than a value that might be selected for the verification service policy for freshness of the "iat" value as described in <xref target="RFC8224" format="default"/> (i.e. six ty seconds). Any reduction in this window makes substitution attacks (see <xref target="sub" format="default"/>) harder to mount, but making the window too smal l might conceivably age PASSporTs out while a heavily redirected call is still a lerting.
</t> </t>
<t> <t>
An alternative potential approach to blind signatures would be the use of oblivi ous pseudorandom functions (VOPRFs, per <xref target="I-D.privacy-pass" format=" default"/>), which move prove faster. An alternative potential approach to blind signatures would be the use of oblivi ous pseudorandom functions (VOPRFs, per <xref target="I-D.privacy-pass" format=" default"/>), which move prove faster.
</t> </t>
</section> </section>
</section> </section>
<section anchor="u8224" numbered="true" toc="default"> <section anchor="u8224" numbered="true" toc="default">
<name>Authentication and Verification Service Behavior for Out-of-Band</na me> <name>Authentication and Verification Service Behavior for Out-of-Band</na me>
<t> <t>
<xref target="RFC8224" format="default"/> defines an authentication servi ce and a verification service as functions that act in the context of SIP reques ts and responses. This specification thus provides a more generic description of authentication service and verification service behavior that might or might no t involve any SIP transactions, but depends only on placing a request for commun ications from <xref target="RFC8224" format="default"/> defines an authentication servi ce and a verification service as functions that act in the context of SIP reques ts and responses. This specification thus provides a more generic description of authentication service and verification service behavior that might or might no t involve any SIP transactions, but depends only on placing a request for commun ications from
an originating identity to one or more destination identities. an originating identity to one or more destination identities.
</t> </t>
<section anchor="as" numbered="true" toc="default"> <section anchor="as" numbered="true" toc="default">
<name>Authentication Service (AS)</name> <name>Authentication Service (AS)</name>
<t> <t>
Out-of-band authentication services perform steps similar to those define d in <xref target="RFC8224" format="default"/> with some exceptions: Out-of-band authentication services perform steps similar to those define d in <xref target="RFC8224" format="default"/> with some exceptions:
</t> </t>
<t> <t>
Step 1: The authentication service MUST determine whether it is 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 als that can be used It can do so only if it possesses the private key of one or more credenti als that can be used
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 associated with a <xref target="RFC8225" format="default">STIR certificate</xre f>. 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 associated with a <xref target="RFC8225" format="default">STIR certificate</xre f>.
</t> </t>
<t> <t>
Step 2: The authentication service MUST determine that the originator of communications can claim the originating identity. This is a policy Step 2: The authentication service <bcp14>MUST</bcp14> determine that the originator of communications can claim the originating identity. This is a poli cy
decision made by the authentication service that depends on its relations hip to the originator. For an out-of-band application built-in to the decision made by the authentication service that depends on its relations hip to the originator. For an out-of-band application built-in to the
calling device, for example, this is the same check performed in Step 1: does the calling device hold a private key, one corresponding to a STIR certific ate, calling device, for example, this is the same check performed in Step 1: does the calling device hold a private key, one corresponding to a STIR certific ate,
that can sign for the originating identity? that can sign for the originating identity?
</t> </t>
<t> <t anchor="as-step3">
Step 3: The authentication service MUST acquire the public encryption key Step 3: The authentication service <bcp14>MUST</bcp14> acquire the public
of the destination, which will be used to encrypt the PASSporT (see <xref targe encryption key of the destination, which will be used to encrypt the PASSporT (
t="lookup" format="default"/>). It MUST also discover (see <xref target="cps" fo see <xref target="lookup" format="default"/>). It <bcp14>MUST</bcp14> also disco
rmat="default"/>) ver (see <xref target="cps" format="default"/>)
the CPS associated with the destination. The authentication service the CPS associated with the destination. The authentication service
may already have the encryption key and destination CPS cached, or may ne ed to query a service to acquire the key. Note that per <xref target="rate-contr ol" format="default"/> the authentication service may also need to acquire a tok en for PASSporT storage from the CPS upon CPS discovery. It is anticipated that the discovery mechanism (see <xref target="cps" format="default"/>) used to find the appropriate may already have the encryption key and destination CPS cached, or may ne ed to query a service to acquire the key. Note that per <xref target="rate-contr ol" format="default"/> the authentication service may also need to acquire a tok en for PASSporT storage from the CPS upon CPS discovery. It is anticipated that the discovery mechanism (see <xref target="cps" format="default"/>) used to find the appropriate
CPS will also find the proper key server for the public key of the destin ation. In some cases, a destination may have multiple public encryption keys ass ociated with it. In that case, the authentication service MUST collect all of th ose keys. CPS will also find the proper key server for the public key of the destin ation. In some cases, a destination may have multiple public encryption keys ass ociated with it. In that case, the authentication service <bcp14>MUST</bcp14> co llect all of those keys.
</t> </t>
<t> <t>
Step 4: The authentication service MUST create the PASSporT object. This Step 4: The authentication service <bcp14>MUST</bcp14> create the PASSpor
includes acquiring the system time to populate the "iat" claim, and populating t T object. This includes acquiring the system time to populate the "iat" claim, a
he "orig" and "dest" claims as nd populating the "orig" and "dest" claims as
described in <xref target="RFC8225" format="default"/>. The authenticatio described in <xref target="RFC8225" format="default"/>. The authenticatio
n service MUST then encrypt the PASSporT. If in Step 3 the authentication servic n service <bcp14>MUST</bcp14> then encrypt the PASSporT. If in Step 3 the authen
e discovered multiple public keys for the destination, it tication service discovered multiple public keys for the destination, it
MUST create one encrypted copy for each public key it discovered. <bcp14>MUST</bcp14> create one encrypted copy for each public key it disc
overed.
</t> </t>
<t> <t>
Finally, the authentication service stores the encrypted PASSporT(s) at t he CPS discovered in Step 3. Only after that is completed should any call be ini tiated. Note that a call might be initiated over SIP, and the authentication Finally, the authentication service stores the encrypted PASSporT(s) at t he CPS discovered in Step 3. Only after that is completed should any call be ini tiated. Note that a call might be initiated over SIP, and the authentication
service would place the same PASSporT in the Identity header field value service would place the same PASSporT in the Identity header field value
of the SIP request - though SIP would carry a cleartext version rather than an e of the SIP request - though SIP would carry a cleartext version rather than an e
ncrypted version sent to the CPS. In that case, out-of-band would serve as a fal ncrypted version sent to the CPS. In that case, out-of-band would serve as a fal
lback mechanism in case the request was not conveyed over SIP end-to-end. Also, lback mechanism in case the request was not conveyed over SIP end-to-end. Also,
note that the authentication service MAY note that the authentication service <bcp14>MAY</bcp14>
use a compact form of the PASSporT for a SIP request, whereas the version use a compact form of the PASSporT for a SIP request, whereas the version
stored at the CPS MUST always be a full form PASSporT. stored at the CPS <bcp14>MUST</bcp14> always be a full form PASSporT.
</t> </t>
</section> </section>
<section anchor="vs" numbered="true" toc="default"> <section anchor="vs" numbered="true" toc="default">
<name>Verification Service (VS)</name> <name>Verification Service (VS)</name>
<t> <t>
When a call arrives, an out-of-band verification service performs steps s imilar to those defined in <xref target="RFC8224" format="default"/> with some e xceptions: When a call arrives, an out-of-band verification service performs steps s imilar to those defined in <xref target="RFC8224" format="default"/> with some e xceptions:
</t> </t>
<t> <t anchor="vs-step1">
Step 1: The verification service contacts the CPS and requests all curren Step 1: The verification service contacts the CPS and requests all curren
t PASSporTs for its destination number; or alternatively it may receive PASSporT t PASSporTs for its destination number; or alternatively it may receive PASSporT
s through a push interface from the CPS in some deployments. The verification se s through a push interface from the CPS in some deployments. The verification se
rvice MUST then decrypt all PASSporTs using its private key. Some PASSporTs may rvice <bcp14>MUST</bcp14> then decrypt all PASSporTs using its private key. Some
not be decryptable for any number of reasons: they may be intended for a differe PASSporTs may not be decryptable for any number of reasons: they may be intende
nt verification service, or they may be "dummy" values inserted by the CPS for p d for a different verification service, or they may be "dummy" values inserted b
rivacy purposes. The next few steps will narrow down the set of PASSporTs that t y the CPS for privacy purposes. The next few steps will narrow down the set of P
he verification service will examine from that initial decryptable set. ASSporTs that the verification service will examine from that initial decryptabl
e set.
</t> </t>
<t> <t>
Step 2: The verification service MUST determine if any "ppt" extensions i n the PASSporTs are unsupported. It takes only the set of supported PASSporTs an d applies the next step to them. Step 2: The verification service <bcp14>MUST</bcp14> determine if any "pp t" extensions in the PASSporTs are unsupported. It takes only the set of support ed PASSporTs and applies the next step to them.
</t> </t>
<t> <t>
Step 3: The verification service MUST determine if there is an overlap be tween the calling party number presented in call signaling and the "orig" field of any decrypted PASSporTs. It takes the set of matching PASSporTs and applies t he next step to them. Step 3: The verification service <bcp14>MUST</bcp14> determine if there i s an overlap between the calling party number presented in call signaling and th e "orig" field of any decrypted PASSporTs. It takes the set of matching PASSporT s and applies the next step to them.
</t> </t>
<t> <t>
Step 4: The verification service MUST determine if the credentials that s igned each PASSporT are valid, and if the verification service trusts the CA tha t issued the credentials. It takes the set Step 4: The verification service <bcp14>MUST</bcp14> determine if the cre dentials that signed each PASSporT are valid, and if the verification service tr usts the CA that issued the credentials. It takes the set
of trusted PASSporTs to the next step. of trusted PASSporTs to the next step.
</t> </t>
<t> <t>
Step 5: The verification service MUST check the freshness of the "iat" cl aim of each PASSporT. The exact interval of time that determines freshness is le ft to local policy. It takes the set of fresh PASSporTs to the next step. 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 freshness is left to local policy. It takes the set of fresh PASSporTs to the ne xt step.
</t> </t>
<t> <t>
Step 6: The verification service MUST check the validity of the signature over each PASSporT, as described in <xref target="RFC8225" format="default"/>. Step 6: The verification service <bcp14>MUST</bcp14> check the validity o f the signature over each PASSporT, as described in <xref target="RFC8225" forma t="default"/>.
</t> </t>
<t> <t>
Finally, the verification service will end up with one or more valid PASS porTs corresponding to the call it has received. In keeping with baseline STIR, this document does not dictate any particular treatment of calls that have valid PASSporTs associated with them; the handling of the call Finally, the verification service will end up with one or more valid PASS porTs corresponding to the call it has received. In keeping with baseline STIR, this document does not dictate any particular treatment of calls that have valid PASSporTs 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 UA implementations.
</t> </t>
</section> </section>
<section anchor="hybrid" numbered="true" toc="default"> <section anchor="hybrid" numbered="true" toc="default">
<name>Gateway Placement Services</name> <name>Gateway Placement Services</name>
<t> <t>
The STIR out-of-band mechanism also supports the presence of gateway plac ement services, which do not create PASSporTs themselves, but instead take PASSp orTs out of signaling protocols and store them at a CPS before gatewaying to a p rotocol that cannot carry PASSporTs itself. For example, a SIP gateway that send s calls to the PSTN could receive a call with an Identity header field, extract a PASSporT from the Identity header field, and store that PASSporT at a CPS. The STIR out-of-band mechanism also supports the presence of gateway plac ement services, which do not create PASSporTs themselves, but instead take PASSp orTs out of signaling protocols and store them at a CPS before gatewaying to a p rotocol that cannot carry PASSporTs itself. For example, a SIP gateway that send s calls to the PSTN could receive a call with an Identity header field, extract a PASSporT from the Identity header field, and store that PASSporT at a CPS.
</t> </t>
<t> <t>
To place a PASSporT at a CPS, a gateway MUST perform Step 3 of <xref targ et="as" format="default"/> above: that is, it must discover the CPS and public k ey associated with the destination of the call, and may need to acquire a PASSpo rT storage token (see <xref target="stor" format="default"/>). Per Step 3 of <xr ef target="as" format="default"/> this may entail discovering several keys. The gateway then collects the in-band PASSporT(s) from the in-band signaling, encryp ts the PASSporT(s), and stores them at the CPS. To place a PASSporT at a CPS, a gateway <bcp14>MUST</bcp14> perform <xref target="as-step3" format="none">Step 3</xref> of <xref target="as" format="defa ult"/> above: that is, it must discover the CPS and public key associated with t he destination of the call, and may need to acquire a PASSporT storage token (se e <xref target="stor" format="default"/>). Per <xref target="as-step3" format="n one">Step 3</xref> of <xref target="as" format="default"/> this may entail disco vering several keys. The gateway then collects the in-band PASSporT(s) from the in-band signaling, encrypts the PASSporT(s), and stores them at the CPS.
</t> </t>
<t> <t>
A similar service could be performed by a gateway that retrieves PASSporT s from a CPS and inserts them into signaling protocols that support carrying PAS SporTS in-band. This behavior may be defined by future specifications. A similar service could be performed by a gateway that retrieves PASSporT s from a CPS and inserts them into signaling protocols that support carrying PAS SporTS in-band. This behavior may be defined by future specifications.
</t> </t>
</section> </section>
</section> </section>
<section anchor="web" numbered="true" toc="default"> <section anchor="web" numbered="true" toc="default">
<name>Example HTTPS Interface to the CPS</name> <name>Example HTTPS Interface to the CPS</name>
<t> <t>
As a rough example, we show a Call Placement Service implementation here which uses a REST API to store and retrieve objects at the CPS. The calling part y stores the PASSporT at the CPS prior to initiating the call; the As a rough example, we show a Call Placement Service implementation here which uses a REST API to store and retrieve objects at the CPS. The calling part y stores the PASSporT at the CPS prior to initiating the call; the
skipping to change at line 704 skipping to change at line 725
</t> </t>
<t> <t>
Assume that an authentication service has created the following PASSporT for a call to the telephone number 2.222.555.2222 (note that these are dummy val ues): Assume that an authentication service has created the following PASSporT for a call to the telephone number 2.222.555.2222 (note that these are dummy val ues):
</t> </t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9 eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9
jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJkZXN0Ijp7InRuIjpbI jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJkZXN0Ijp7InRuIjpbI
jIyMjI1NTUyMjIyIl19LCJpYXQiOiIxNTgzMjUxODEwIiwib3JpZyI6eyJ0biI6 jIyMjI1NTUyMjIyIl19LCJpYXQiOiIxNTgzMjUxODEwIiwib3JpZyI6eyJ0biI6
IjExMTE1NTUxMTExIn19.pnij4IlLHoR4vxID0u3CT1e9Hq4xLngZUTv45Vbxmd IjExMTE1NTUxMTExIn19.pnij4IlLHoR4vxID0u3CT1e9Hq4xLngZUTv45Vbxmd
3IVyZug4KOSa378yfP4x6twY0KTdiDypsereS438ZHaQ 3IVyZug4KOSa378yfP4x6twY0KTdiDypsereS438ZHaQ
]]></artwork> ]]></artwork>
<t> <t>
Through some discovery mechanism (see <xref target="cps" format="default" />), the authentication service discovers the network location of a web service that acts as the CPS for 2.222.555.2222. Through the same mechanism, we will say that it has also discovered one public encryption key for that destination. It uses that encryption key to encrypt the PASSporT, resulting in the encrypted PAS SporT: Through some discovery mechanism (see <xref target="cps" format="default" />), the authentication service discovers the network location of a web service that acts as the CPS for 2.222.555.2222. Through the same mechanism, we will say that it has also discovered one public encryption key for that destination. It uses that encryption key to encrypt the PASSporT, resulting in the encrypted PAS SporT:
</t> </t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w
MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm
nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV
wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1 wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1
IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j
]]></artwork> ]]></artwork>
<t> <t>
Having concluded the numbered steps in <xref target="as" format="default "/>, including acquiring any token (per <xref target="stor" format="default"/>) needed to store the PASSporT at the CPS, the authentication service then stores the encrypted PASSporT: Having concluded the numbered steps in <xref target="as" format="default "/>, including acquiring any token (per <xref target="stor" format="default"/>) needed to store the PASSporT at the CPS, the authentication service then stores the encrypted PASSporT:
</t> </t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
POST /cps/2.222.555.2222/ppts HTTP/1.1 POST /cps/2.222.555.2222/ppts HTTP/1.1
Host: cps.example.com Host: cps.example.com
Content-Type: application/passport Content-Type: application/passport
rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w
MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm
nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV
wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1 wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1
IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j
]]></artwork> ]]></artwork>
<t> <t>
The web service assigns a new location for this encrypted PASSporT in the collection, returning a 201 OK with the location of /cps/2.222.222.2222/ppts/pp t1. The web service assigns a new location for this encrypted PASSporT in the collection, returning a 201 OK with the location of /cps/2.222.222.2222/ppts/pp t1.
Now the authentication service can place the call, which may be signaled by various protocols. Once the call arrives at the terminating side, a verificat ion service Now the authentication service can place the call, which may be signaled by various protocols. Once the call arrives at the terminating side, a verificat ion service
contacts its CPS to ask for the set of incoming calls for its telephone n umber (2.222.222.2222). contacts its CPS to ask for the set of incoming calls for its telephone n umber (2.222.222.2222).
</t> </t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![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>
<t> <t>
This returns to the verification service a list of the PASSporTs current ly in the collection, which currently consists of only /cps/2.222.222.2222/ppts/ ppt1. The verification This returns to the verification service a list of the PASSporTs current ly in the collection, which currently consists of only /cps/2.222.222.2222/ppts/ ppt1. The verification
service then sends a new GET for /cps/2.222.555.2222/ppts/ppt1/ which yi elds: service then sends a new GET for /cps/2.222.555.2222/ppts/ppt1/ which yi elds:
</t> </t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/passport Content-Type: application/passport
Link: <https://cps.example.com/cps/2.222.555.2222/ppts> Link: <https://cps.example.com/cps/2.222.555.2222/ppts>
rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w
MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm
nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV
wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1 wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1
IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j
]]></artwork> ]]></artwork>
<t> <t>
That concludes Step 1 of <xref target="vs" format="default"/>; the verif ication service then goes on to the next step, processing that PASSporT through its various checks. A complete protocol description for CPS interactions is left to future work. That concludes <xref target="vs-step1" format="none">Step 1</xref> of <x ref target="vs" format="default"/>; the verification service then goes on to the next step, processing that PASSporT through its various checks. A complete prot ocol description for CPS interactions is left to future work.
</t> </t>
</section> </section>
<section anchor="cps" numbered="true" toc="default"> <section anchor="cps" numbered="true" toc="default">
<name>CPS Discovery</name> <name>CPS Discovery</name>
<t> <t>
In order for the two ends of the out-of-band dataflow to coordinate, they must agree on a way to discover a CPS and retrieve PASSporT objects from it In order for the two ends of the out-of-band dataflow to coordinate, they must agree on a way to discover a CPS and retrieve PASSporT objects from it
based solely on the rendezvous information available: the calling party n umber and the called number. Because the storage of PASSporTs in this architectu re is indexed based solely on the rendezvous information available: the calling party n umber and the called number. Because the storage of PASSporTs in this architectu re is indexed
by the called party number, it makes sense to discover a CPS based on the called party number as well. by the called party number, it makes sense to discover a CPS based on the called party number as well.
There are a number of potential service discovery mechanisms that could b e used for There are a number of potential service discovery mechanisms that could b e used for
this purpose. The means of service discovery may vary by use case. this purpose. The means of service discovery may vary by use case.
skipping to change at line 862 skipping to change at line 883
every potential caller. every potential caller.
</t> </t>
<t> <t>
We consider the exact best point in the tradeoff space to be an open We consider the exact best point in the tradeoff space to be an open
issue. issue.
</t> </t>
</section> </section>
<section anchor="Acknowledgments" numbered="true" toc="default"> <section anchor="Acknowledgments" numbered="true" toc="default">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>The ideas <t>The ideas
in this document come out of discussions with Richard Barnes and Cullen in this document come out of discussions with <contact fullname="Richard Barn
Jennings. We'd also like to thank Russ Housley, Chris Wendt, Eric Burger, Mar es"/> and
y Barnes, Ben Campbell, Ted Huang, <contact fullname="Cullen Jennings"/>. We'd also like to thank
Jonathan Rosenberg and Robert Sparks for helpful suggestions.</t> <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>
<section anchor="IANA" numbered="true" toc="default"> <section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This memo includes no request to IANA.</t> <t>This memo includes no request to IANA.</t>
</section> </section>
<section anchor="priv" numbered="true" toc="default"> <section anchor="priv" numbered="true" toc="default">
<name>Privacy Considerations</name> <name>Privacy Considerations</name>
<t> <t>
Delivering PASSporTs out-of-band offers a different set of privacy propertie s than traditional in-band STIR. In-band operations convey Delivering PASSporTs out-of-band offers a different set of privacy propertie s than traditional in-band STIR. In-band operations convey
PASSporTs as headers in SIP messages in cleartext, which any forwarding inte rmediaries can potentially inspect. By contrast, out-of-band PASSporTs as headers in SIP messages in cleartext, which any forwarding inte rmediaries can potentially inspect. By contrast, out-of-band
skipping to change at line 910 skipping to change at line 935
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 in <xref target="sec" format="default"/> and <xref target="sub" format="default "/>, along proposed solutions for problems like denial-of-service attacks or tra ffic analysis against the CPS.</t> with the most obvious security challenges posed by this framework is given in <xref target="sec" format="default"/> and <xref target="sub" format="default "/>, along proposed solutions for problems like denial-of-service attacks or tra ffic analysis against the CPS.</t>
<t>Although there are considerable security challenges associated with wid espread deployment of a public CPS, those must be weighed against the potential usefulness of a service that delivers a STIR assurance without requiring the pas sage of end-to-end SIP. Ultimately, the security properties of this mechanism ar e at least comparable to in-band <t>Although there are considerable security challenges associated with wid espread deployment of a public CPS, those must be weighed against the potential usefulness of a service that delivers a STIR assurance without requiring the pas sage of end-to-end SIP. Ultimately, the security properties of this mechanism ar e at least comparable to in-band
STIR: the substitution attack documented in <xref target="sub" format=" default"/> could be implemented by any in-band SIP intermediary or eavesdropper who happened to see the PASSporT in transit, say, and launch its own call with a copy of that PASSporT to race against the original to the destination. STIR: the substitution attack documented in <xref target="sub" format=" default"/> could be implemented by any in-band SIP intermediary or eavesdropper who happened to see the PASSporT in transit, say, and launch 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 MATTER ***** -->
<back> <back>
<displayreference target="I-D.ietf-stir-passport-divert" to="PASSPORT-DIVERT"/>
<displayreference target="I-D.ietf-modern-teri" to="MODERN-TERI"/>
<displayreference target="I-D.ietf-tls-subcerts" to="TLS-SUBCERTS"/>
<displayreference target="I-D.privacy-pass" to="PRIVACY-PASS"/>
<displayreference target="I-D.jennings-vipr-overview" to="VIPR-OVERVIEW"/>
<!-- References split into informative and normative --> <!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation librarie s: <!-- There are 2 ways to insert reference entries from the citation librarie s:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here ( as shown) 1. define an ENTITY at the top, and use "ampersand character"RFC2629; here ( as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml "?> here 2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml "?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.x ml") (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.x ml")
Both are cited textually in the same manner: by using xref elements. Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included fil es in the same If you use the PI option, xml2rfc will, by default, try to find included fil es in the same
directory as the including file. You can also define the XML_LIBRARY environ ment variable directory as the including file. You can also define the XML_LIBRARY environ ment variable
skipping to change at line 939 skipping to change at line 971
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.7258.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.7258.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.3261.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.3261.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.6116.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.6116.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.6940.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.6940.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.7748.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.7748.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.8224.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.8224.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.8225.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.8225.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.8226.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.8226.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.8174.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.8446.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.8446.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
nce.I-D.draft-ietf-stir-passport-divert-08.xml"/> <!-- [rfced] [I-D.draft-ietf-stir-passport-divert] IESG state IESG Evaluation --
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere >
nce.I-D.draft-ietf-modern-teri-00.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere D.ietf-stir-passport-divert.xml"/>
nce.I-D.draft-ietf-tls-subcerts-07.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere <!-- [rfced] [I-D.draft-ietf-modern-teri] IESG state Expired -->
nce.I-D.draft-privacy-pass-00.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere D.ietf-modern-teri.xml"/>
nce.I-D.draft-jennings-vipr-overview-06.xml"/>
<!-- [rfced] [I-D.draft-ietf-tls-subcerts] IESG state I-D Exists -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-
D.ietf-tls-subcerts.xml"/>
<!-- [rfced] [I-D.draft-privacy-pass] IESG state I-D Exists -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-
D.privacy-pass.xml"/>
<!-- [rfced] [I-D.draft-jennings-vipr-overview] IESG state Expired -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-
D.jennings-vipr-overview.xml"/>
</references> </references>
</back> </back>
</rfc> </rfc>
 End of changes. 43 change blocks. 
108 lines changed or deleted 154 lines changed or added

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