rfc8946xml2.original.xml   rfc8946.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!--
vim:et:ts=2:sw=2:spell:spelllang=en:tw=80
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
.2119.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8174.xml">
<!ENTITY RFC3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.3261.xml">
<!ENTITY RFC5806 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5806.xml">
<!ENTITY RFC7044 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7044.xml">
<!ENTITY RFC7340 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7340.xml">
<!ENTITY RFC7519 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7519.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">
<!ENTITY RFC8443 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8443.xml">
<!ENTITY I-D.ietf-stir-oob SYSTEM "http://xml.resource.org/public/rfc/bibxml3/re
ference.I-D.ietf-stir-oob.xml">
]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
<!--?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?--> docName="draft-ietf-stir-passport-divert-09" number="8946"
<!-- used by XSLT processors --> ipr="trust200902" updates="8224" obsoletes="" submissionType="IETF"
<!-- For a complete list and description of processing instructions (PIs), category="std" consensus="true" xml:lang="en" tocInclude="true"
please see http://xml.resource.org/authoring/README.html. --> tocDepth="4" symRefs="true" sortRefs="true" version="3">
<!-- 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="std" docName="draft-ietf-stir-passport-divert-09"
ipr="trust200902" updates="RFC8224">
<!-- 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 MATTER ***** -->
<front> <front>
<!-- The abbreviated title is used in the page header - it is only necessary
if the
full title is longer than 39 characters -->
<title abbrev="PASSporT Diverted">PASSporT Extension for Diverted Calls</tit <title abbrev="PASSporT Diverted">Personal Assertion Token (PASSporT)
le> Extension for Diverted Calls</title>
<author initials="J." surname="Peterson" fullname="Jon Peterson"> <seriesInfo name="RFC" value="8946"/>
<organization abbrev="Neustar">Neustar, Inc.</organization> <author initials="J." surname="Peterson" fullname="Jon Peterson">
<address> <organization abbrev="Neustar">Neustar, Inc.</organization>
<postal> <address>
<street>1800 Sutter St Suite 570</street> <postal>
<city>Concord</city> <street>1800 Sutter St., Suite 570</street>
<region>CA</region> <city>Concord</city>
<code>94520</code> <region>CA</region>
<country>US</country> <code>94520</code>
</postal> <country>United States of America</country>
<email>jon.peterson@team.neustar</email> </postal>
</address> <email>jon.peterson@team.neustar</email>
</author> </address>
</author>
<date year="2020" /> <date year="2021" month="February" />
<!-- <area> <area>ART</area>
ART <workgroup>STIR</workgroup>
</area>-->
<keyword>SIP</keyword> <keyword>SIP</keyword>
<keyword>STIR</keyword> <keyword>STIR</keyword>
<keyword>Identity</keyword> <keyword>Identity</keyword>
<abstract> <abstract>
<t> <t>The Personal Assertion Token (PASSporT) is specified in RFC 8225 to
PASSporT is specified in RFC 8225 to convey cryptographically-signed in convey cryptographically signed
formation about the people involved in personal communications. This document ex information about the people involved in personal communications. This
tends PASSporT to include an indication that a call has document extends PASSporT to include an indication that a call has been
been diverted from its original destination to a new one. This informat diverted from its original destination to a new one. This information
ion can greatly improve the decisions made by verification services in call forw can greatly improve the decisions made by verification services in call
arding scenarios. Also specified forwarding scenarios. Also specified here is an encapsulation mechanism
here is an encapsulation mechanism for nesting a PASSporT within anothe for nesting a PASSporT within another PASSporT that assists relying
r PASSporT that assists relying parties in some diversion scenarios. parties in some diversion scenarios.</t>
</t> <t>This document updates RFC 8224.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" title="Introduction"> <section anchor="intro" numbered="true" toc="default">
<t> <name>Introduction</name>
A Personal Assertion Token (<xref target="RFC8225">PASSporT</xref>) is a <t>A Personal Assertion Token (PASSporT) <xref target="RFC8225"
token format based on the JSON Web Token (<xref target="RFC7519">JWT</xref>) for format="default"/> is a token format based on the JSON
conveying cryptographically-signed information about the people involved in per Web Token (JWT) <xref target="RFC7519" format="default"/> for
sonal communications; it is used by the Secure Telephone Identity Revisited (<xr conveying cryptographically signed information about the people involved
ef target="RFC8224">STIR</xref>) protocol to convey a signed assertion of the id in personal communications; it is used by the Secure Telephone Identity
entity Revisited (STIR) protocol <xref target="RFC8224" format="default"/>
of the participants in real-time communications established via a protoco to convey a signed assertion of the identity of the participants in
l like SIP. This specification extends PASSporT to include an indication that a real-time communications established via a protocol like SIP. This
call has specification extends PASSporT to include an indication that a call has
been diverted from its original destination to a new one. been diverted from its original destination to a new one.</t>
</t><t> <t>Although the <xref target="RFC7340" format="default">STIR problem
Although the <xref target="RFC7340">STIR problem statement</xref> is focu statement</xref> is focused on preventing the impersonation of the
sed on preventing the impersonation of the caller's identity, which is a common caller's identity, which is a common enabler for threats such as
enabler for threats such as robocalling and voicemail hacking on the telephone n robocalling and voicemail hacking on the telephone network today, it
etwork today, it also provides a signature over the called number at the time th also provides a signature over the called number at the time that the
at the authentication service sees it. As <xref target="RFC8224"/> Section 12.1 authentication service sees it. As <xref target="RFC8224"
describes, this protection over the contents of the To header field is intended sectionFormat="comma" section="12.1"/> describes, this protection over the
to prevent a class of cut-and-paste attacks. If Alice calls Bob, for example, Bo contents of the To header field is intended to prevent a class of
b might attempt to cut-and-paste the Identity header field in Alice's INVITE int cut-and-paste attacks. If Alice calls Bob, for example, Bob might
o a new INVITE that Bob sends to Carol, and thus be able to fool Carol into thin attempt to cut and paste the Identity header field in Alice's INVITE
king the call came from Alice and not Bob. With the signature over the To header into a new INVITE that Bob sends to Carol, and thus be able to fool
field value, the INVITE Carol sees will clearly have been destined originally f Carol into thinking the call came from Alice and not Bob. With the
or Bob, and thus Carol can view the INVITE as suspect. signature over the To header field value, the INVITE Carol sees will
</t><t> clearly have been destined originally for Bob, and thus Carol can view
However, as <xref target="RFC8224"/> Section 12.1.1 points out, the INVITE as suspect.</t>
it is difficult for Carol to confirm or reject these suspicions based on <t>However, as <xref target="RFC8224" sectionFormat="comma" section="12.1.
the information she receives from the baseline PASSporT object. 1"/>
The common "call forwarding" service serves as a good example of the real points out, it is difficult for Carol to confirm or reject these
ity that the original called party number is not always the number to which a ca suspicions based on the information she receives from the baseline
ll is delivered. PASSporT object. The common "call forwarding" service serves as a good
There are a number of potential ways for intermediaries to indicate that example of the reality that the original called party number is not
such a forwarding operating has taken place. The address in the always the number to which a call is delivered. There are a number of
To header field value of SIP requests is not supposed to change, accordin potential ways for intermediaries to indicate that such a forwarding
g to baseline SIP behavior <xref target="RFC3261"/>; instead, it is the Request- operating has taken place. The address in the To header field value of
URI that is supposed to be updated when a call is retargeted. Practically speaki SIP requests is not supposed to change, according to baseline SIP
ng, however, many operational environments do alter the To header field. The <xr behavior <xref target="RFC3261" format="default"/>; instead, it is the
ef target="RFC7044">History-Info header field</xref> was created to store the Re Request-URI that is supposed to be updated when a call is
quest-URIs that are discarded by a call in transit. The <xref target="RFC5806">S retargeted. Practically speaking, however, many operational environments
IP Diversion header field</xref>, though historic, is still used for this purpos do alter the To header field. The <xref target="RFC7044"
e by some operators today. Neither of format="default">History-Info header field</xref> was created to store
these header fields provide any cryptographic assurance of secure redirec the Request-URIs that are discarded by a call in transit. The <xref
tion, and they both record entries for minor syntactical changes in URIs that do target="RFC5806" format="default">SIP Diversion header field</xref>,
not reflect a change to the actual target of a call. though historic, is still used for this purpose by some operators
</t><t> today. Neither of these header fields provide any cryptographic
This specification therefore extends PASSporT with an explicit indication assurance of secure redirection, and they both record entries for minor
that the original called number in PASSporT no longer reflects the destination syntactical changes in URIs that do not reflect a change to the actual
to which a call is intended to be delivered. For this purpose, it specifies a Di target of a call.</t>
vert PASSporT type ("div") for use in common SIP retargeting cases; it is expect <t>Therefore, this specification extends PASSporT with an explicit
ed that in this case, SIP INVITE requests will carry multiple Identity header fi indication that the original called number in PASSporT no longer
elds, each containing its own PASSporT. Throughout this document, PASSporTs that reflects the destination to which a call is intended to be
contain a "div" element will be referred to as "div" PASSporTs. Verification se delivered. For this purpose, it specifies a Divert PASSporT type ("div")
rvices and the relying parties who make authorization decisions about communicat for use in common SIP retargeting cases; it is expected that in this
ions may use this diversion indication to confirm that a legitimate retargeting case, SIP INVITE requests will carry multiple Identity header fields,
of the call has taken place, rather each containing its own PASSporT. Throughout this document, PASSporTs
than a cut-and-paste attack. For <xref target="I-D.ietf-stir-oob">out-of- that contain a "div" element will be referred to as "div"
band</xref> use cases, and other non-SIP applications of PASSporT, a separate "d PASSporTs. Verification services and the relying parties who make
iv-o" PASSporT type is also specified, which defines an "opt" PASSporT element f authorization decisions about communications may use this diversion
or carrying nested PASSporTs within a PASSporT. These shall in turn be referred indication to confirm that a legitimate retargeting of the call has
to in this document as "div-o" PASSporTs. taken place, rather than a cut-and-paste attack. For <xref
</t> target="RFC8816" format="default">out-of-band use cases</xref> and
other non-SIP applications of PASSporT, a separate "div-o" PASSporT type
is also specified, which defines an "opt" PASSporT element for carrying
nested PASSporTs within a PASSporT. These shall in turn be referred to
in this document as "div-o" PASSporTs.</t>
</section> </section>
<section anchor="terminology" numbered="true" toc="default">
<section anchor="terminology" title="Terminology"> <name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT <t>
", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
and NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"OPTIONAL" in this document are to be interpreted as described i "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
n "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, a to be interpreted as
nd only when, they appear in all described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
capitals, as shown here.</t> when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section anchor="syntax" numbered="true" toc="default">
<section anchor="syntax" title="The 'div' PASSporT Type and Claim"> <name>The "div" PASSporT Type and Claim</name>
<t> <t>This specification defines a <xref target="RFC8225"
This specification defines a <xref target="RFC8225">PASSporT</xref> typ format="default">PASSporT</xref> type called "div", which may be employed
e called "div" that may be employed by authentication services located at retarg by authentication services located at retargeting entities. All "div"
eting entities. All "div" PASSporTs MUST contain a PASSporTs <bcp14>MUST</bcp14> contain a new JSON Web Token "div" claim, al
new JSON Web Token "div" claim, also specified in this document, which so specified
indicates a previous destination for a call during its routing process. When a r in this document, which indicates a previous destination for a call
etargeting entity receives a call signed with a PASSporT, it may act as an authe during its routing process. When a retargeting entity receives a call
ntication service and create a new PASSporT containing the "div" claim to attach signed with a PASSporT, it may act as an authentication service and
to the call. create a new PASSporT containing the "div" claim to attach to the
</t><t> call.</t>
Note that a new PASSporT is only necessary when the canonical form of the "dest" <t>Note that a new PASSporT is only necessary when the canonical form of
identifier (per the canonicalization procedures in <xref target="RFC8224"/> Sec the "dest" identifier (per the canonicalization procedures in <xref
tion 8.3) changes due to this retargeting. If the canonical form of the "dest" i target="RFC8224" sectionFormat="comma" section="8.3"/>) changes due to thi
dentifier is not changed during retargeting, then a new PASSporT with a "div" cl s
aim MUST NOT be produced. retargeting. If the canonical form of the "dest" identifier is not
</t><t> changed during retargeting, then a new PASSporT with a "div" claim <bcp14>
The headers of the new PASSporTs generated by retargeting entities MUST include MUST
the "div" PASSporT NOT</bcp14> be produced.</t>
type, and an "x5u" field pointing to a credential that the retarg <t>The headers of the new PASSporTs generated by retargeting entities
eting entity controls. "div" PASSporTs MUST use full form instead of compact for <bcp14>MUST</bcp14> include the "div" PASSporT type and an "x5u" field poi
m. nting to a
The new PASSporT header will look as follows: credential that the retargeting entity controls. "div" PASSporTs <bcp14>MU
</t> ST</bcp14>
<figure> use full form instead of compact form. The new PASSporT header will look
<artwork><![CDATA[ as follows:</t>
<sourcecode><![CDATA[
{ "typ":"passport", { "typ":"passport",
"ppt":"div", "ppt":"div",
"alg":"ES256", "alg":"ES256",
"x5u":"https://www.example.com/cert.cer" } "x5u":"https://www.example.com/cert.cer" }
]]></artwork> ]]></sourcecode>
</figure> <t>A "div" PASSporT claims set is populated with elements drawn from the
<t> PASSporT(s) received for a call by the retargeting entity; at a high
A "div" PASSporT claims set is populated with elements drawn from the P level, the original identifier for the called party in the "dest" object
ASSporT(s) received for a call by the retargeting entity: at a high level, the o will become the "div" claim in the new PASSporT. If the "dest" object of
riginal identifier for the called party the original PASSporT contains multiple identifiers, because it contains
in the "dest" object will become the "div" claim in the new PASSporT. one or more name/value pairs with an array as its value, the retargeting
If the "dest" object of the original PASSporT contains multiple identif entity <bcp14>MUST</bcp14> select only one identifier from the value(s) of
iers, because it contains one or more name/value pairs with an array as its valu the "dest"
e, the retargeting object to occupy the value of the "div" field in the new
entity MUST select only one identifier from the value(s) of the "dest" PASSporT. Moreover, it <bcp14>MUST</bcp14> select an identifier that is wi
object to occupy the value of the "div" field in the new PASSporT. Moreover, it thin the
MUST select an identifier that is within the scope of the credential that the re scope of the credential that the retargeting entity will specify in the
targeting entity will specify in the "x5u" of the PASSporT header (as described "x5u" of the PASSporT header (as described below).</t>
below). <t>The new target for the call selected by the retargeting entity
</t><t> becomes the value of the "dest" object of the new PASSporT. The "orig"
The new target for the call selected by the retargeting entity becomes object <bcp14>MUST</bcp14> be copied into the new PASSporT from the origin
the value of the "dest" object of the new PASSporT. The "orig" object MUST be co al PASSporT
pied into the new PASSporT from the original PASSporT received by the retargetin received by the retargeting entity. The retargeting entity <bcp14>SHOULD</
g entity. The retargeting entity SHOULD retain the "iat" object from the origina bcp14> retain
l PASSporT, though if in the underlying signaling protocol (e.g. SIP) the retar the "iat" object from the original PASSporT, though if in the underlying
geting entity changes the date and time information in the retargeted request, t signaling protocol (e.g., SIP) the retargeting entity changes the date
he new PASSporT should instead reflect that date and time. No other claims or ex and time information in the retargeted request, the new PASSporT should
tensions are to be copied from the original PASSporT to the "div" PASSporT. instead reflect that date and time. No other claims or extensions are to
</t><t>So, for an original PASSporT claims set of the form: be copied from the original PASSporT to the "div" PASSporT.</t>
</t> <t>So, for an original PASSporT claims set of the form:</t>
<figure> <sourcecode><![CDATA[
<artwork><![CDATA[
{ "dest":{"tn":["12155551213"]}, { "dest":{"tn":["12155551213"]},
"iat":1443208345, "iat":1443208345,
"orig":{"tn":"12155551212"} } "orig":{"tn":"12155551212"} }
]]></artwork> ]]></sourcecode>
</figure> <t>If the retargeting entity is changing the target from 12155551213 to
<t>If the retargeting entity is changing the target from 12155551 12155551214, the claims set of a "div" PASSporT generated by the
213 to 12155551214, the claims set of a "div" PASSpoRT generated by the retarget retargeting entity would look as follows:</t>
ing entity would look as follows:</t> <sourcecode><![CDATA[
<figure>
<artwork><![CDATA[
{ "dest":{"tn":["12155551214"]}, { "dest":{"tn":["12155551214"]},
"div":{"tn":"121555551213"}, "div":{"tn":"121555551213"},
"iat":1443208345, "iat":1443208345,
"orig":{"tn":"12155551212"} } "orig":{"tn":"12155551212"} }
]]></artwork> ]]></sourcecode>
</figure> <t>The combined full form PASSporT (with a signature covered by the
<t> ES256 keys given in <xref target="keys" format="default"/>) would look
The combined full form PASSporT (with a signature covered by the ES256 as follows:</t>
keys given in <xref target="keys"/>) would look as follows: <sourcecode><![CDATA[
</t> eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdiIsInR5cCI6InBhc3Nwb3J0IiwieDV1Ij \
<figure> oiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQ.eyJkZXN0Ijp7InRuI \
<artwork><![CDATA[ jpbIjEyMTU1NTUxMjE0Il19LCJkaXYiOnsidG4iOiIxMjE1NTU1NTEyMTMifSwiaWF \
eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdiIsInR5cCI6InBhc3Nwb3J0IiwieDV1Ij \ 0IjoxNDQzMjA4MzQ1LCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.xBHWipDEE \
oiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQ.eyJkZXN0Ijp7InRuI \ J8a6TsdX6xUXAnblsFiGUiAxwLiv0HLC9IICj6eG9jQd6WzeSSjHRBwxmChHhVIiMT \
jpbIjEyMTU1NTUxMjE0Il19LCJkaXYiOnsidG4iOiIxMjE1NTU1NTEyMTMifSwiaWF \ SqIlk3yCNkg
0IjoxNDQzMjA4MzQ1LCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.xBHWipDEE \ ]]></sourcecode>
J8a6TsdX6xUXAnblsFiGUiAxwLiv0HLC9IICj6eG9jQd6WzeSSjHRBwxmChHhVIiMT \ <t>The same "div" PASSporT would result if the "dest" object of the
SqIlk3yCNkg original PASSporT contained an array value, such as
]]></artwork> {"tn":["12155551213","19995551234"]}, and the retargeting entity chose
</figure> to retarget from the first telephone number in the array. Every "div"
<t> PASSporT is diverting from only one identifier.</t>
The same "div" PASSporT would result if the "dest" object of the origin <t>Note that the "div" element may contain other name/value pairs than
al PASSporT contained an array value, such as {"tn":["12155551213","19995551234" just a destination, including a History-Info indicator (see <xref
]}, and the retargeting entity chose to retarget from the first telephone number target="hi" format="default"/>). After the PASSporT header and claims
in the array. Every "div" PASSporT is diverting from only one identifier. have been constructed, their signature is generated per the guidance in
</t><t> <xref target="RFC8225" format="default"/> -- except for the credential
Note that the "div" element may contain other name/value pairs than jus required to sign it. While in the ordinary construction of a PASSporT,
t a destination, including a History-Info indicator (see <xref target="hi"/>). A the credential used to sign will have authority over the identity in the
fter the PASSporT header and claims have been constructed, their signature is ge "orig" claim (for example, a certificate with authority over the
nerated per the guidance in <xref target="RFC8225"/> - except for telephone number in "orig" per <xref target="RFC8226"
the credential required to sign it. While in the ordinary construction format="default"/>), for all PASSporTs using the "div" type the
of a PASSporT, the credential used to sign will have authority over the identity signature <bcp14>MUST</bcp14> be created with a credential with authority
in the "orig" claim (for example, a over the
certificate with authority over the telephone number in "orig" per <xre identity present in the "div" claim. So for the example above, where the
f target="RFC8226"/>), for all PASSporTs using the "div" type the signature MUST original "dest" is "12155551213", the signer of the new PASSporT object
be created with a credential with authority over the <bcp14>MUST</bcp14> have authority over that telephone number and need not
identity present in the "div" claim. So for the example above, where th have any
e original "dest" is "12155551213", the signer of the new PASSporT object MUST h authority over the telephone number present in the "orig" claim.</t>
ave authority over that telephone number, and need not <t>Note that Identity header fields are not ordered in a SIP request,
have any authority over the telephone number present in the "orig" clai and in a case where there is a multiplicity of Identity header fields in
m. a request, some sorting may be required to match "div" PASSporTs to
</t><t> their originals.</t>
Note that Identity header fields are not ordered in a SIP request, and i <t>PASSporTs of type "div" <bcp14>MUST NOT</bcp14> contain an "opt" (see <
n a case where there is a multiplicity of Identity header fields in a request, s xref
ome sorting may be required to match "div" PASSporTs to their originals. target="opt" format="default"/>) element in their payload.</t>
</t><t>
PASSporTs of type "div" MUST NOT contain an "opt" (see <xref target="opt
"/>) element in their payload.
</t>
</section>
<section anchor="use" title="Using 'div' in SIP">
<t>
This section specifies SIP-specific usage for the "div" PASSporT type a
nd its handling in the SIP Identity header field "ppt" parameter value. Other pr
otocols using PASSporT may define behavior specific to their use of the "div" cl
aim.
</t>
<section anchor="as" title="Authentication Service Behavior">
<t>
An authentication service only adds an Identity header field valu
e containing the "div" PASSporT type to a SIP request that already contains at l
east one Identity header field value; it MUST NOT add a
"div" PASSporT to an INVITE that contains no Identity header fiel
d. The retargeting entity SHOULD act as a verification service and validate the
existing Identity header field value(s) in the request before proceeding; in som
e high-volume environments, it may instead put that burden of validating the cha
in entirely on the terminating verification service. As the authentication servi
ce will be adding a new PASSporT that refers to an original, it MUST NOT remove
the original request's Identity header field value before forwarding.
</t><t>
As was stated in <xref target="syntax"/>, the authentication serv
ice MUST sign any "div" PASSporT with a credential that has a scope of authority
covering the identity it populates in the "div" element value. Note that this i
s a significant departure from baseline STIR authentication service behavior, in
which the PASSporT is signed by a credential with authority over the "orig" fie
ld. The "div" value reflects the URI that caused the call to be routed to the re
targeting entity, so in ordinary operations, it would already be the STIR entity
holding the appropriate private keying material for calls originating from that
identity.
</t>
<t>
A SIP authentication service typically will derive the "dest" element v
alue of a "div" PASSporT from a new Request-URI that is set for the SIP request
before it is forwarded. Older values of the Request-URI may appear in header fie
lds like Diversion or History-Info; this document specifies an optional interact
ion with History-Info below in <xref target="hi"/>. Note as well
that because PASSporT operates on canonicalized telephone numbers and n
ormalized URIs, many smaller changes to the syntax of identifiers that might be
captured by other mechanisms that
record retargeting (like History-Info) will likely not require a "div"
PASSporT.
</t>
<t>
When adding an Identity header field with a PASSporT claims set contain
ing a "div" claim, SIP authentication services MUST also add a "ppt" parameter t
o that Identity header with a value of "div". For the example PASSporT given in
<xref target="syntax"/>, the new Identity header added after retargeting might l
ook as follows:
</t>
<figure>
<artwork>
<![CDATA[
Identity:eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdiIsInR5cCI6InBhc3Nwb3J0I \
iwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQ.eyJkZXN0 \
Ijp7InRuIjpbIjEyMTU1NTUxMjE0Il19LCJkaXYiOnsidG4iOiIxMjE1NTU1NTEyMT \
MifSwiaWF0IjoxNDQzMjA4MzQ1LCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0. \
xBHWipDEEJ8a6TsdX6xUXAnblsFiGUiAxwLiv0HLC9IICj6eG9jQd6WzeSSjHRBwxm \
ChHhVIiMTSqIlk3yCNkg; \
info=<https://www.example.com/cert.cer>;ppt="div"
]]>
</artwork>
</figure>
<t>
Note that in some deployments, an authentication service will need to gen
erate "div" PASSporTs for a request that contains multiple non-"div" Identity he
ader field values. For example, a request arriving at a retargeting entity might
contain in different Identity header fields a baseline <xref target="RFC8224"/>
PASSporT and a PASSporT of type <xref target="RFC8443">"rph"</xref> signed by a
separate authority. Provided that these PASSporTs share the same "orig" and "de
st" values, the retargeting entity's authentication service SHOULD generate only
one "div" PASSporT. If the "orig" or "dest" of these PASSporTs differ, however,
one "div" PASSporT SHOULD be generated for each non-"div" PASSporT. Note that t
his effectively creates multiple chains of "div" PASSporTs in a single request,
which complicates the procedures that need to be performed at verification servi
ces.
</t><t>
Furthermore, a request may also be retargeted a second time, at which poi
nt the subsequent retargeting entity SHOULD generate one "div" PASSporT for each
previous "div" PASSporT in the request which contains a "dest" object with the
value of the current target - but not for "div" PASSporTs with earlier targets.
Ordinarily, the current target will be readily identifiable, as it will be in th
e last "div" PASSporT in each chain, and in SIP cases it will correspond to the
Request-URI received by the retargeting entity. Moreover, the current target wil
l be an identifier that the retargeting entity possesses a credential to sign fo
r, which may not be true for earlier targets. Ultimately, on each retargeting, t
he number of PASSporTs added to a request will be equal to the number of non-"di
v" PASSporTs that do not share the same "orig" and "dest" object values.
</t>
</section>
<section anchor="vs" title="Verification Service Behavior">
<t>
<xref target="RFC8224"/> Section 6.2 Step 5 requires that specification
s defining "ppt" values describe any additional or alternative verifier behavior
.
The job of a SIP verification service handling one or more "div" PASSpo
rTs is very different from that of a traditional verification service. At a high
level, the immediate responsibility of the verification service is to extract a
ll PASSporTs from the two or more Identity header fields in a request, identify
which are "div" PASSporTs and which are not, and then order and link the "div" P
ASSporTs to the original PASSporT(s) in order to build one or more chains of ret
argeting.
</t><t>
In order to validate a SIP request using the "div" PASSporT type, a veri
fication service needs to inspect all of the valid Identity header field values
associated with a request, as an Identity header field value containing "div" ne
cessarily refers to an earlier PASSporT already in the message. For each "div" P
ASSporT, the verification service MUST find an earlier PASSporT that contains a
"dest" claim with a value equivalent to the "div" claim in each "div" PASSporT.
It is possible that this earlier PASSporT will also contain a "div", and that it
will in turn chain to a still earlier PASSporT stored in a different Identity h
eader field value. If a complete chain cannot be constructed, the verification s
ervice cannot complete "div" validation; it MAY still validate any non-"div" PAS
SporTs in the request per normal <xref target="RFC8224"/> procedures. If a chain
has been successfully constructed, the verification service extracts from the o
utermost (that is, the most recent) PASSporT in the chain a "dest" field; this w
ill be a "div" PASSporT that no other "div" PASSporT in the SIP request refers t
o. Its "dest" element value will be referred to in the procedures that follow as
the value of the "outermost "dest" field."
</t><t>
Ultimately, by looking at this chain of transformations and validating t
he associated signatures, the verification service will be able to ascertain tha
t the appropriate parties were responsible for the retargeting of the call to it
s current destination. This can help the verification service to determine that
the original PASSporT in the call was not simply used in a cut-and-paste attack
and inform any associated authorization decisions in terms of how the call will
be treated - though, per <xref target="RFC8224"/> Section 6.2.1, that decision i
s a matter of local policy and is thus outside the scope of this specification.
</t><t>
A verification service parses a chain of PASSporTs as follows:
</t>
<t><list><t>
First, the verification service MUST compare the value in the outermost "
dest" field to the target of the call. As it is anticipated that SIP authenticat
ion services that create "div" PASSporTs will populate the "dest" header from th
e retargeted Request-URI (see <xref target="as"/>), in ordinary SIP operations,
the Request-URI is where verification services will find the latest call target.
Note however that after a "div" PASSporT has been added to a SIP request, the R
equest-URI may have been updated during normal call processing to an identifier
that no longer contains the logical destination of a call; in this case, the ver
ification service MAY compare the "dest" field to a provisioned telephone number
for the recipient.
</t><t>
Second, the verification service MUST validate the signature over the out
ermost "div" PASSporT, and establish that the credential that signed the "div" P
ASSporT has the authority to attest for the identifier in the "div" element of t
he PASSporT (per <xref target="RFC8224"/> Section 6.2 Step 3).
</t><t>
Third, the verification service MUST validate that the "orig" field of th
e innermost PASSporT of the chain (the only PASSporT in the chain which will not
be of PASSporT type "div") is equivalent to the "orig" field of the outermost "
div" PASSporT; in other words, that the original calling identifier has not been
altered by retargeting authentication services. If the "orig" value has changed
, the verification service MUST treat the entire PASSporT chain as invalid. The
verification service MUST also verify that all other "div" PASSporTs in the chai
n share the same "orig" value. Then the verification service validates the relat
ionship of the "orig" field to the SIP-level call signaling per the guidance in
<xref target="RFC8224"/> Section 6.2 Step 2.
</t><t>
Fourth, the verification service MUST check the date freshness in the out
ermost "div" PASSporT per <xref target="RFC8224"/> Section 6.2 Step 4. It is fur
thermore RECOMMENDED that the verification service check that the "iat" field of
the innermost PASSporT is also within the date freshness interval; otherwise th
e verification service could allow attackers to replay an old, stale PASSporT em
bedded in a fresh "div". However, note that in some use cases, including certain
ways that call transfers are implemented, it is possible that an established ca
ll will be retargeted long after it has originally been placed, and verification
services may want to allow a longer window for the freshness of the innermost P
ASSporT if the call is transferred from a trusted party (as an upper bound, a fr
eshness window on the order of three hours might suffice).
</t><t>
Fifth, the verification service MUST inspect and validate the signa
tures on each and every PASSporT object in the chain between the outermost "div"
PASSporT and the innermost PASSporT. Note that (per <xref target="as"/>) a chai
n may terminate at more than one innermost PASSporT, in cases where a single "di
v" is used to retarget from multiple innermost PASSporTs. Also note that <xref t
arget="RFC8224"/> Section 6.2 Step 1 applies to the chain validation process: if
the innermost PASSporT contains an unsupported "ppt", its chain MUST be ignored
.
</t></list></t>
<t>
Note that the To header field is not used in the first step above. Option
ally, the verification service MAY verify that the To header field value of the
received SIP signaling is equal to the "dest" value in the innermost PASSporT; h
owever, as has been observed in some deployments, the original To header field v
alue may be altered by intermediaries to reflect changes of target. Deployments
that change the original To header field value to conceal the original destinati
on of the call from the ultimate recipient should note that the original destina
tion of a call may be preserved in the innermost PASSporT. Future work on "div"
might explore methods to implement that sort of policy while retaining a secure
chain of redirection.
</t>
</section> </section>
</section> <section anchor="use" numbered="true" toc="default">
<name>Using "div" in SIP</name>
<t>This section specifies SIP-specific usage for the "div" PASSporT type
and its handling in the SIP Identity header field "ppt" parameter
value. Other protocols using PASSporT may define behavior specific to
their use of the "div" claim.</t>
<section anchor="as" numbered="true" toc="default">
<name>Authentication Service Behavior</name>
<t>An authentication service only adds an Identity header field value
containing the "div" PASSporT type to a SIP request that already
contains at least one Identity header field value; it <bcp14>MUST NOT</bc
p14> add a
"div" PASSporT to an INVITE that contains no Identity header
field. The retargeting entity <bcp14>SHOULD</bcp14> act as a verification
service and
validate the existing Identity header field value(s) in the request
before proceeding; in some high-volume environments, it may instead
put that burden of validating the chain entirely on the terminating
verification service. As the authentication service will be adding a
new PASSporT that refers to an original, it <bcp14>MUST NOT</bcp14> remov
e the
original request's Identity header field value before forwarding.</t>
<t>As was stated in <xref target="syntax" format="default"/>, the
authentication service <bcp14>MUST</bcp14> sign any "div" PASSporT with a
credential
that has a scope of authority covering the identity it populates in
the "div" element value. Note that this is a significant departure
from baseline STIR authentication service behavior, in which the
PASSporT is signed by a credential with authority over the "orig"
field. The "div" value reflects the URI that caused the call to be
routed to the retargeting entity, so in ordinary operations, it would
already be the STIR entity holding the appropriate private keying
material for calls originating from that identity.</t>
<t>A SIP authentication service typically will derive the "dest"
element value of a "div" PASSporT from a new Request-URI that is set
for the SIP request before it is forwarded. Older values of the
Request-URI may appear in header fields like Diversion or
History-Info; this document specifies an optional interaction with
History-Info below in <xref target="hi" format="default"/>. Note as
well that because PASSporT operates on canonicalized telephone numbers
and normalized URIs, many smaller changes to the syntax of identifiers
that might be captured by other mechanisms that record retargeting
(like History-Info) will likely not require a "div" PASSporT.</t>
<t>When adding an Identity header field with a PASSporT claims set
containing a "div" claim, SIP authentication services <bcp14>MUST</bcp14>
also add a
"ppt" parameter to that Identity header with a value of "div". For the
example PASSporT given in <xref target="syntax" format="default"/>,
the new Identity header added after retargeting might look as
follows:</t>
<sourcecode><![CDATA[
Identity:eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdiIsInR5cCI6InBhc3Nwb3J0I \
iwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQ.eyJkZXN0 \
Ijp7InRuIjpbIjEyMTU1NTUxMjE0Il19LCJkaXYiOnsidG4iOiIxMjE1NTU1NTEyMT \
MifSwiaWF0IjoxNDQzMjA4MzQ1LCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0. \
xBHWipDEEJ8a6TsdX6xUXAnblsFiGUiAxwLiv0HLC9IICj6eG9jQd6WzeSSjHRBwxm \
ChHhVIiMTSqIlk3yCNkg; \
info=<https://www.example.com/cert.cer>;ppt="div"
]]></sourcecode>
<t>Note that in some deployments, an authentication service will need
to generate "div" PASSporTs for a request that contains multiple
non-"div" Identity header field values. For example, a request
arriving at a retargeting entity might contain, in different Identity
header fields, a baseline <xref target="RFC8224" format="default"/>
PASSporT and a PASSporT of type <xref target="RFC8443"
format="default">"rph"</xref> signed by a separate authority. Provided
that these PASSporTs share the same "orig" and "dest" values, the
retargeting entity's authentication service <bcp14>SHOULD</bcp14> generat
e only one
"div" PASSporT. If the "orig" or "dest" of these PASSporTs differ,
however, one "div" PASSporT <bcp14>SHOULD</bcp14> be generated for each n
on-"div"
PASSporT. Note that this effectively creates multiple chains of "div"
PASSporTs in a single request, which complicates the procedures that
need to be performed at verification services.</t>
<t>Furthermore, a request may also be retargeted a second time, at
which point the subsequent retargeting entity <bcp14>SHOULD</bcp14> gener
ate one
"div" PASSporT for each previous "div" PASSporT in the request that
contains a "dest" object with the value of the current target -- but
not for "div" PASSporTs with earlier targets. Ordinarily, the current
target will be readily identifiable, as it will be in the last "div"
PASSporT in each chain, and in SIP cases, it will correspond to the
Request-URI received by the retargeting entity. Moreover, the current
target will be an identifier that the retargeting entity possesses a
credential to sign for, which may not be true for earlier
targets. Ultimately, on each retargeting, the number of PASSporTs
added to a request will be equal to the number of non-"div" PASSporTs
that do not share the same "orig" and "dest" object values.</t>
</section>
<section anchor="vs" numbered="true" toc="default">
<name>Verification Service Behavior</name>
<t><xref target="RFC8224" sectionFormat="comma" section="6.2"/>, Step 5
requires that specifications defining "ppt" values describe any
additional or alternative verifier behavior. The job of a SIP
verification service handling one or more "div" PASSporTs is very
different from that of a traditional verification service. At a high
level, the immediate responsibility of the verification service is to
extract all PASSporTs from the two or more Identity header fields in a
request, identify which are "div" PASSporTs and which are not, and
then order and link the "div" PASSporTs to the original PASSporT(s) in
order to build one or more chains of retargeting.</t>
<t>In order to validate a SIP request using the "div" PASSporT type, a
verification service needs to inspect all of the valid Identity header
field values associated with a request, as an Identity header field
value containing "div" necessarily refers to an earlier PASSporT
already in the message. For each "div" PASSporT, the verification
service <bcp14>MUST</bcp14> find an earlier PASSporT that contains a
"dest" claim with a value equivalent to the "div" claim in each "div"
PASSporT. It is possible that this earlier PASSporT will also contain
a "div" and that it will in turn chain to a still earlier PASSporT
stored in a different Identity header field value. If a complete chain
cannot be constructed, the verification service cannot complete "div"
validation; it <bcp14>MAY</bcp14> still validate any non-"div"
PASSporTs in the request per the normal procedures in <xref
target="RFC8224" format="default"/>. If a chain has been successfully
constructed, the verification service extracts from the outermost
(that is, the most recent) PASSporT in the chain a "dest" field; this
will be a "div" PASSporT that no other "div" PASSporT in the SIP
request refers to. Its "dest" element value will be referred to in the
procedures that follow as the value of the "outermost "dest"
field".</t>
<t>Ultimately, by looking at this chain of transformations and
validating the associated signatures, the verification service will be
able to ascertain that the appropriate parties were responsible for
the retargeting of the call to its current destination. This can help
the verification service to determine that the original PASSporT in
the call was not simply used in a cut-and-paste attack and inform any
associated authorization decisions in terms of how the call will be
treated -- though, per <xref target="RFC8224" sectionFormat="comma"
section="6.2.1"/>, that decision is a matter of local policy and is
thus outside the scope of this specification.</t>
<t>A verification service parses a chain of PASSporTs as follows:</t>
<section anchor="divo" title="The 'div-o' PASSporT Type"> <ol type="1">
<t> <li>The verification service <bcp14>MUST</bcp14> compare the value in
This specification defines a "div-o" PASSporT type that uses the "div" the
claim element in conjunction with the <xref target="opt">"opt"</xref> claim elem outermost "dest" field to the target of the call. As it is
ent. As is the case with "div" PASSporT type, a "div-o" PASSporT is created by a anticipated that SIP authentication services that create "div"
n authentication service acting for a retargeting entity, but instead of generat PASSporTs will populate the "dest" header from the retargeted
ing a separate "div" PASSporT to be conveyed alongside an original PASSporT, the Request-URI (see <xref target="as" format="default"/>), in ordinary
authentication service in this case embeds the original PASSporT inside the "op SIP operations, the Request-URI is where verification services will
t" element of the "div-o" PASSporT. The "div-o" extension is designed for use find the latest call target. Note, however, that after a "div"
in non-SIP or gatewayed SIP environments where the conveyance of PASSporTs in s PASSporT has been added to a SIP request, the Request-URI may have
eparate Identity header fields in impossible, such as <xref target="I-D.ietf-sti been updated during normal call processing to an identifier that no
r-oob">out-of-band</xref> STIR scenarios. longer contains the logical destination of a call; in this case, the
</t><t> verification service <bcp14>MAY</bcp14> compare the "dest" field to a p
The syntax of "div-o" PASSporTs is very similar to "div". A "div-o" PAS rovisioned
SporT header object might look as follows: telephone number for the recipient.</li>
</t> <li>The verification service <bcp14>MUST</bcp14> validate the signatur
<figure> e
<artwork><![CDATA[ over the outermost "div" PASSporT and establish that the credential
that signed the "div" PASSporT has the authority to attest for the
identifier in the "div" element of the PASSporT (per <xref
target="RFC8224" sectionFormat="comma" section="6.2"/>, Step 3).</li>
<li>The verification service <bcp14>MUST</bcp14> validate that the "or
ig"
field of the innermost PASSporT of the chain (the only PASSporT in
the chain that will not be of PASSporT type "div") is equivalent to
the "orig" field of the outermost "div" PASSporT; in other words, that
the original calling identifier has not been altered by retargeting
authentication services. If the "orig" value has changed, the
verification service <bcp14>MUST</bcp14> treat the entire PASSporT
chain as invalid. The verification service <bcp14>MUST</bcp14> also
verify that all other "div" PASSporTs in the chain share the same
"orig" value. Then, the verification service validates the
relationship of the "orig" field to the SIP-level call signaling per
the guidance in <xref target="RFC8224" sectionFormat="comma"
section="6.2"/>, Step 2.</li>
<li>The verification service <bcp14>MUST</bcp14> check the date freshn
ess
in the outermost "div" PASSporT, per <xref target="RFC8224"
sectionFormat="comma" section="6.2"/>, Step 4. Furthermore, it is <bcp1
4>RECOMMENDED</bcp14>
that the verification service check that the "iat" field of the
innermost PASSporT is also within the date freshness interval;
otherwise, the verification service could allow attackers to replay
an old, stale PASSporT embedded in a fresh "div". However, note that
in some use cases, including certain ways that call transfers are
implemented, it is possible that an established call will be
retargeted long after it has originally been placed, and
verification services may want to allow a longer window for the
freshness of the innermost PASSporT if the call is transferred from
a trusted party (as an upper bound, a freshness window on the order
of three hours might suffice).</li>
<li>The verification service <bcp14>MUST</bcp14> inspect and validate
the
signatures on each and every PASSporT object in the chain between
the outermost "div" PASSporT and the innermost PASSporT. Note that
(per <xref target="as" format="default"/>) a chain may terminate at
more than one innermost PASSporT, in cases where a single "div" is
used to retarget from multiple innermost PASSporTs. Also note that
<xref target="RFC8224" sectionFormat="comma" section="6.2"/>, Step 1 ap
plies
to the chain validation process; if the innermost PASSporT contains
an unsupported "ppt", its chain <bcp14>MUST</bcp14> be ignored.</li>
</ol>
<t>Note that the To header field is not used in the first step
above. Optionally, the verification service <bcp14>MAY</bcp14> verify tha
t the To
header field value of the received SIP signaling is equal to the
"dest" value in the innermost PASSporT; however, as has been observed
in some deployments, the original To header field value may be altered
by intermediaries to reflect changes of target. Deployments that
change the original To header field value to conceal the original
destination of the call from the ultimate recipient should note that
the original destination of a call may be preserved in the innermost
PASSporT. Future work on "div" might explore methods to implement that
sort of policy while retaining a secure chain of redirection.</t>
</section>
</section>
<section anchor="divo" numbered="true" toc="default">
<name>The "div-o" PASSporT Type</name>
<t>This specification defines a "div-o" PASSporT type that uses the
"div" claim element in conjunction with the <xref target="opt"
format="default">"opt"</xref> claim element. As is the case with "div"
PASSporT type, a "div-o" PASSporT is created by an authentication
service acting for a retargeting entity, but instead of generating a
separate "div" PASSporT to be conveyed alongside an original PASSporT,
the authentication service in this case embeds the original PASSporT
inside the "opt" element of the "div-o" PASSporT. The "div-o" exten
sion
is designed for use in non-SIP or gatewayed SIP environments where the
conveyance of PASSporTs in separate Identity header fields in
impossible, such as <xref target="RFC8816"
format="default">out-of-band STIR scenarios</xref>.</t>
<t>The syntax of "div-o" PASSporTs is very similar to "div". A "div-o"
PASSporT header object might look as follows:</t>
<sourcecode><![CDATA[
{ "typ":"passport", { "typ":"passport",
"ppt":"div-o", "ppt":"div-o",
"alg":"ES256", "alg":"ES256",
"x5u":"https://www.example.com/cert.cer" } "x5u":"https://www.example.com/cert.cer" }
]]></artwork> ]]></sourcecode>
</figure> <t>Whereas a "div" PASSporT claims set contains only the "orig", "dest",
<t> "iat", and "div" elements, the "div-o" additionally <bcp14>MUST</bcp14> co
Whereas a "div" PASSporT claims set contains only the "orig", "dest", " ntain an
iat", and "div" elements, the "div-o" additionally MUST contain an "opt" element "opt" element (see <xref target="opt" format="default"/>), which
(see <xref target="opt"/>), which encapsulates the full form of the pre encapsulates the full form of the previous PASSporT from which the call
vious PASSporT from which the call was retargeted, triggering the generation of was retargeted, triggering the generation of this "div-o". The format of
this "div-o". The format of the "opt" element is identical to the encoded PASSpo the "opt" element is identical to the encoded PASSporT format given in
rT format given in Appendix A of <xref target="RFC8225"/>. <xref target="RFC8225" sectionFormat="of" section="A"/>.</t>
</t><t>So, for an original PASSporT claims set of the form: <t>So, for an original PASSporT claims set of the form:</t>
</t> <sourcecode><![CDATA[
<figure>
<artwork><![CDATA[
{ "orig":{"tn":"12155551212"}, { "orig":{"tn":"12155551212"},
"dest":{"tn":["12155551213"]}, "dest":{"tn":["12155551213"]},
"iat":1443208345 } "iat":1443208345 }
]]></artwork> ]]></sourcecode>
</figure> <t>If the retargeting entity is changing the target from 12155551213 to
<t>If the retargeting entity is changing the target from 12155551 12155551214, the new PASSporT claims set for "div-o" would look as
213 to 12155551214, the new PASSporT claims set for "div-o" would look as follow follows:</t>
s:</t> <sourcecode><![CDATA[
<figure> { "orig":{"tn":"12155551212"},
<artwork><![CDATA[ "dest":{"tn":["12155551214"]},
{ "orig":{"tn":"12155551212"}, "iat":1443208345,
"dest":{"tn":["12155551214"]}, "div":{"tn":"121555551213"},
"iat":1443208345, "opt":"eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0c \
"div":{"tn":"121555551213"}, HM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQ.eyJkZXN0Ijp7InRuIjpbIj \
"opt":"eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0c \ EyMTU1NTUxMjEzIl19LCJpYXQiOjE0NDMyMDgzNDUsIm9yaWciOnsidG4iOiIxMj \
HM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQ.eyJkZXN0Ijp7InRuIjpbIj \ E1NTU1MTIxMiJ9fQ.1bEzkzcNbKvgz4QoMx0_DJ2T8qFMDC1sPqHPXl1WvbauzRJ \
EyMTU1NTUxMjEzIl19LCJpYXQiOjE0NDMyMDgzNDUsIm9yaWciOnsidG4iOiIxMj \ RvYlZqQ0qgGTlS8tJ_wXjVe07Z3wvDrdApHhhYw" }
E1NTU1MTIxMiJ9fQ.1bEzkzcNbKvgz4QoMx0_DJ2T8qFMDC1sPqHPXl1WvbauzRJ \ ]]></sourcecode>
RvYlZqQ0qgGTlS8tJ_wXjVe07Z3wvDrdApHhhYw" } <t>While in ordinary operations, it is not expected that SIP would carry
]]></artwork> a "div-o" PASSporT, it might be possible in some gatewaying
</figure> scenarios. The resulting full form Identity header field with a "div-o"
<t> PASSporT would look as follows:</t>
While in ordinary operations, it is not expected that SIP would carry a <sourcecode><![CDATA[
"div-o" PASSporT, it might be possible in some gatewaying scenarios. The result Identity:eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdi1vIiwidHlwIjoicGFzc3Bvc \
ing full form Identity header field with a "div-o" PASSporT would look as follow nQiLCJ4NXUiOiJodHRwczovL3d3dy5leGFtcGxlLmNvbS9jZXJ0LmNlciJ9.eyJkZX \
s: N0Ijp7InRuIjoiMTIxNTU1NTEyMTQifSwiZGl2Ijp7InRuIjoiMTIxNTU1NTUxMjEz \
</t> In0sImlhdCI6MTQ0MzIwODM0NSwib3B0IjoiZXlKaGJHY2lPaUpGVXpJMU5pSXNJbl \
<figure> I1Y0NJNkluQmhjM053YjNKMElpd2llRFYxSWpvaWFIUjBjSE02THk5M2QzY3VaWGho \
<artwork><![CDATA[ YlhCc1pTNWpiMjB2WTJWeWRDNWpaWElpZlEuZXlKa1pYTjBJanA3SW5SdUlqcGJJak \
Identity:eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdi1vIiwidHlwIjoicGFzc3Bvc \ V5TVRVMU5UVXhNakV6SWwxOUxDSnBZWFFpT2pFME5ETXlNRGd6TkRVc0ltOXlhV2Np \
nQiLCJ4NXUiOiJodHRwczovL3d3dy5leGFtcGxlLmNvbS9jZXJ0LmNlciJ9.eyJkZX \ T25zaWRHNGlPaUl4TWpFMU5UVTFNVEl4TWlKOWZRLjFiRXpremNOYkt2Z3o0UW9NeD \
N0Ijp7InRuIjoiMTIxNTU1NTEyMTQifSwiZGl2Ijp7InRuIjoiMTIxNTU1NTUxMjEz \ BfREoyVDhxRk1EQzFzUHFIUFhsMVd2YmF1elJKUnZZbFpxUTBxZ0dUbFM4dEpfd1hq \
In0sImlhdCI6MTQ0MzIwODM0NSwib3B0IjoiZXlKaGJHY2lPaUpGVXpJMU5pSXNJbl \ VmUwN1ozd3ZEcmRBcEhoaFl3Iiwib3JpZyI6eyJ0biI6IjEyMTU1NTUxMjEyIn19.C \
I1Y0NJNkluQmhjM053YjNKMElpd2llRFYxSWpvaWFIUjBjSE02THk5M2QzY3VaWGho \ HeA9wRnthl7paMe6rP0TARpmFCXjmi_vF_HRz2O_oulB_R-G9xZNiLVvmvHv4gk6LI \
YlhCc1pTNWpiMjB2WTJWeWRDNWpaWElpZlEuZXlKa1pYTjBJanA3SW5SdUlqcGJJak \ LaDV2y2VtHTLIEgmHig; \
V5TVRVMU5UVXhNakV6SWwxOUxDSnBZWFFpT2pFME5ETXlNRGd6TkRVc0ltOXlhV2Np \ info=<https://www.example.com/cert.cer>;ppt="div-o"
T25zaWRHNGlPaUl4TWpFMU5UVTFNVEl4TWlKOWZRLjFiRXpremNOYkt2Z3o0UW9NeD \ ]]></sourcecode>
BfREoyVDhxRk1EQzFzUHFIUFhsMVd2YmF1elJKUnZZbFpxUTBxZ0dUbFM4dEpfd1hq \ <section anchor="optasvs" numbered="true" toc="default">
VmUwN1ozd3ZEcmRBcEhoaFl3Iiwib3JpZyI6eyJ0biI6IjEyMTU1NTUxMjEyIn19.C \ <name>Processing "div-o" PASSporTs</name>
HeA9wRnthl7paMe6rP0TARpmFCXjmi_vF_HRz2O_oulB_R-G9xZNiLVvmvHv4gk6LI \ <t>The authentication and verification service procedures required for
LaDV2y2VtHTLIEgmHig; \ "div-o" closely follow the guidance given in Sections <xref target="as"
info=<https://www.example.com/cert.cer>;ppt="div-o" format="counter"/> and <xref target="vs" format="counter"/>, with the
]]></artwork> major caveats being, first, that they do store or retrieve PASSporTs
</figure> via the Identity header field values of SIP requests and, second, that
<section anchor="optasvs" title="Processing 'div-o' PASSporTs"> they process nested PASSporTs in the "opt" claim element. But
<t> transposing the rest of the behaviors described above to creating and
The authentication and verification service procedures required for "div validating "div-o" PASSporTs is straightforward.</t>
-o" closely follow the guidance given in <xref target="as"/> and <xref target="v <t>For the "div-o" PASSporT type, retargeting authentication services
s"/>, with the major caveats being first, that they do store or retrieve PASSpor that handle calls with one or more existing PASSporTs will create a
Ts via the Identity header field values of SIP requests, and second, that they p corresponding "div-o" PASSporT for each received PASSporT. Each
rocess nested PASSporTs in the "opt" claim element. But transposing the rest of "div-o" PASSporT <bcp14>MUST</bcp14> contain an "opt" claim set
the behaviors described above to creating and validating "div-o" PASSporTs is st element with the value of the original PASSporT from which the "div-o"
raightforward. was created; as specified in <xref target="as"
</t><t> format="default"/>, the authentication service <bcp14>MUST</bcp14>
For the "div-o" PASSporT type, retargeting authentication services that populate the "div" claim set element of the "div-o" PASSporT with the
handle calls with one or more existing PASSporTs will create a corresponding "di "dest" field of the original PASSporT. Each received PASSporT may in
v-o" PASSporT for each received PASSporT. Each "div-o" PASSporT turn contain its own "opt" claim set element if the retargeting
MUST contain an "opt" claim set element with the value of the original authentication service is not the first in its chain. Note that if the
PASSporT from which the "div-o" was created; and as specified in <xref target="a retargeting authentication service is handling a call with multiple
s"/>, the authentication service MUST populate the "div" claim set element of th PASSporTs, which in ordinary SIP operation would result in the
e "div-o" PASSporT with the "dest" field fo the original PASSporT. Each received construction of multiple "div" chains, it will in effect be generating
PASSporT may in turn contain its own "opt" claim set element, if the retargetin one "div-o" PASSporT per chain.</t>
g authentication service is not the first in its chain. Note that if the retarge <t>The job of a verification service is in many ways easier for
ting authentication service is handling a call with multiple PASSporTs, which in "div-o" than for "div", as the verification service has no need to
ordinary SIP operation would result in the construction of multiple "div" chain correlate the PASSporTs it receives and assemble them into chains, as
s, it will in effect be generating one "div-o" PASSporT per chain. any chains in "div-o" will be nested through the "opt"
</t><t> element. Nonetheless, the verification services <bcp14>MUST</bcp14> perfo
The job of a verification service is in many ways easier for "div-o" than rm the same
for "div", as the verification service has no need to correlate the PASSporTs i chain validation described in <xref target="vs" format="default"/> to
t receives and assemble them into chains, as any chains in "div-o" will be neste validate that each nested PASSporT shares the same "orig" field as its
d through the "opt" element. Nonetheless, the verification services MUST perform enclosing PASSporT and that the "dest" field of each nested PASSporT
the same chain validation described in <xref target="vs"/> to validate that eac corresponds to the "div" field of its enclosing PASSporT. The same
h nested PASSporT shares the same "orig" field as its enclosing PASSporT, and th checks <bcp14>MUST</bcp14> also be performed for freshness, signature val
at the "dest" field of each nested PASSporT corresponds to the "div" field of it idation, and
s enclosing PASSporT. The same checks MUST also be performed for freshness, sign so on. It is similarly <bcp14>OPTIONAL</bcp14> for the verification servi
ature validation, and so on. It is similarly OPTIONAL for the verification servi ce to
ce to determine that the "dest" claims element of the outermost PASSporT corresp determine that the "dest" claims element of the outermost PASSporT
onds to the called party indication of receive telephone signaling, where such i corresponds to the called party indication of receive telephone
ndication would vary depending on the using protocol. signaling, where such indication would vary depending on the using
</t><t> protocol. </t>
How authentication services or verification services receive or transport PA <t>How authentication services or verification services receive or
SSporTs for "div-o" is outside the scope of this document, and dependent on the transport PASSporTs for "div-o" is outside the scope of this document
using protocol. and dependent on the using protocol.</t>
</t> </section>
</section>
<section anchor="opt" numbered="true" toc="default">
<name>Definition of "opt"</name>
<t>The presence of an "Original PASSporT" ("opt") claims set element
signifies that a PASSporT encapsulates another entire PASSporT within
it, typically a PASSporT that was transformed in some way to create the
current PASSporT. Relying parties may need to consult the encapsulated
PASSporT in order to validate the identity of a caller. "opt", as defined
in this specification, may be used by future PASSporT extensions as well
as in conjunction with "div-o".</t>
<t>"opt" <bcp14>MUST</bcp14> contain a quoted full-form PASSporT, as
specified by <xref target="RFC8225" sectionFormat="comma" section="A"/>; i
t
<bcp14>MUST NOT</bcp14> contain a compact form PASSporT. For an example
of a "div-o" PASSporT containing "opt", see <xref target="divo"
format="default"/>.</t>
</section> </section>
</section>
<section anchor="opt" title="Definition of 'opt'">
<t>
The presence of an "Original PASSporT" ("opt") claims set element signifi
es that a PASSporT encapsulates another entire PASSporT within it, typically a P
ASSporT that was transformed in some way to create the current PASSporT. Relying
parties may need to consult the encapsulated PASSporT in order to validate the
identity of a caller. "opt" as defined in this specification may be used by futu
re PASSporT extensions as well as in conjunction with "div-o".
</t><t>
"opt" MUST contain a quoted full-form PASSporT as specified by <xref targ
et="RFC8225"/> Appendix A; it MUST NOT contain a compact form PASSporT. For an e
xample of a "div-o" PASSporT containing "opt," see <xref target="divo"/>.
</t>
</section>
<section anchor="redir" title="'div' and Redirection"> <section anchor="redir" numbered="true" toc="default">
<t> <name>"div" and Redirection</name>
The "div" mechanism exists primarily to prevent false negatives at verifi <t>The "div" mechanism exists primarily to prevent false negatives at
cation services when an arriving SIP request, due to intermediary retargeting, d verification services when an arriving SIP request, due to intermediary
oes not appear to be intended for its eventual recipient, because the original P retargeting, does not appear to be intended for its eventual recipient,
ASSporT "dest" value designates a different destination. because the original PASSporT "dest" value designates a different
</t><t> destination.</t>
Any intermediary that assigns a new target to a request can, instead of r <t>Any intermediary that assigns a new target to a request can, instead
etargeting and forwarding the request, instead redirect with a 3xx response code of retargeting and forwarding the request, redirect with a 3xx
. In ordinary operations, a redirection poses no difficulties for the response code. In ordinary operations, a redirection poses no
operations of baseline STIR: when the user agent client (UAC) receives th difficulties for the operations of baseline STIR: when the user agent
e 3xx response, it will initiate a new request to the new target (typically the client (UAC) receives the 3xx response, it will initiate a new request
target carried in the Contact header field value of the 3xx), and the "dest" of to the new target (typically the target carried in the Contact header
the PASSporT created for the new request will match that new target. As no impe field value of the 3xx), and the "dest" of the PASSporT created for the
rsonation attack can arise from this case, it creates no new requirements for ST new request will match that new target. As no impersonation attack can
IR. arise from this case, it creates no new requirements for STIR.</t>
</t><t> <t>However, some UACs record the original target of a call with
However, some UACs record the original target of a call with mechanisms l mechanisms like <xref target="RFC7044"
ike <xref target="RFC7044">History-Info</xref> or <xref target="RFC5806">Diversi format="default">History-Info</xref> or <xref target="RFC5806"
on</xref>, and may want to leverage STIR to demonstrate to the ultimate recipien format="default">Diversion</xref> and may want to leverage STIR to
t that the call has been redirected securely: that is, that the original destina demonstrate to the ultimate recipient that the call has been redirected
tion was the one that sent the redirection message that led to the recipient rec securely, that is, that the original destination was the one that sent
eiving the request. The semantics of the PASSporT necessary for that assertion a the redirection message that led to the recipient receiving the
re the same as those for the "div" retargeting cases above. The only wrinkle is request. The semantics of the PASSporT necessary for that assertion are
that the PASSporT needs to be generated by the redirecting entity and sent back the same as those for the "div" retargeting cases above. The only
to the originating user agent client within the 3xx response. wrinkle is that the PASSporT needs to be generated by the redirecting
</t><t> entity and sent back to the originating user agent client within the 3xx
This introduces more complexity than might immediately be apparent. In the f response.</t>
irst place, a 3xx response can convey multiple targets through the Contact heade <t>This introduces more complexity than might immediately be
r field value; to accommodate this, the "div" PASSporT MAY include one "dest" ob apparent. In the first place, a 3xx response can convey multiple targets
ject array value per Contact, but if the retargeting entity wants to keep the Co through the Contact header field value; to accommodate this, the "div"
ntact list private from targets, it may need to generate one PASSporT per Contac PASSporT <bcp14>MAY</bcp14> include one "dest" object array value per Cont
t. Bear in mind as well that the original SIP request could have carried multipl act, but if
e Identity header field values that had been added by different authentication s the retargeting entity wants to keep the Contact list private from
ervices in the request path, so a redirecting entity might need to generate one targets, it may need to generate one PASSporT per Contact. Bear in mind
"div" PASSporT for each PASSporT in the original request. Often, this will mean as well that the original SIP request could have carried multiple
just one "div" PASSporT, but for some deployment scenarios, it could require an Identity header field values that had been added by different
impractical number of combinations. But in very complex call routing scenarios, authentication services in the request path, so a redirecting entity
attestation of source identity would only add limited value anyway. might need to generate one "div" PASSporT for each PASSporT in the
</t><t> original request. Often, this will mean just one "div" PASSporT, but for
STIR-aware SIP intermediaries that redirect requests MAY therefore convey some deployment scenarios, it could require an impractical number of
one or more PASSporTs in the backwards direction within Identity header fields. combinations. But in very complex call routing scenarios, attestation of
These redirecting entities will act as authentication services for "div" as des source identity would only add limited value anyway.</t>
cribed in <xref target="as"/>. This document consequently updates <xref target=" <t>Therefore, STIR-aware SIP intermediaries that redirect requests
RFC8224"/> to permit carrying Identity header fields in SIP 300-class responses. <bcp14>MAY</bcp14> convey one or more PASSporTs in the
It is left to the originating user agent to determine which Identity header fie backwards direction within Identity header fields. These redirecting
lds should be copied from the 3xx into any new requests resulting from the redir entities will act as authentication services for "div" as described in
ection, if any: use of these Identity header fields by entities receiving a 3xx <xref target="as" format="default"/>. This document consequently updates
response is OPTIONAL. <xref target="RFC8224" format="default"/> to permit carrying Identity
</t><t> header fields in SIP 300-class responses. It is left to the originating
Finally, note that if an intermediary in the response path consumes the 3 user agent to determine which Identity header fields should be copied
xx and explores new targets itself while performing sequential forking, it will from the 3xx into any new requests resulting from the redirection, if
effectively retarget the call on behalf of the redirecting server, and this will any; use of these Identity header fields by entities receiving a 3xx
create the same need for "div" PASSporTs as any other retargeted call. These in response is <bcp14>OPTIONAL</bcp14>.</t>
termediaries MAY also copy PASSporTs from the 3xx response and insert them into <t>Finally, note that if an intermediary in the response path consumes
sequential forking requests, if appropriate. the 3xx and explores new targets itself while performing sequential
</t> forking, it will effectively retarget the call on behalf of the
</section> redirecting server, and this will create the same need for "div"
PASSporTs as any other retargeted call. These intermediaries <bcp14>MAY</b
cp14> also
copy PASSporTs from the 3xx response and insert them into sequential
forking requests, if appropriate.</t>
</section>
<section anchor="hi" numbered="true" toc="default">
<name>Extending "div" to Work with Service Logic Tracking</name>
<t>It is anticipated that "div" may be used in concert with <xref
target="RFC7044" format="default">History-Info</xref> in some
deployments. It may not be clear from the "orig" and "dest" values which
History-Info header a given PASSporT correlates to, especially because
some of the target changes tracked by History-Info will not be reflected
in a "div" PASSporT (see <xref target="intro"
format="default"/>).
<section anchor="hi" title="Extending 'div' to work with Service Logic Tr Therefore, an "hi" element as defined here may
acking"> appear in "div" corresponding to the History-Info header field index
<t> parameter value. So for a History-Info header field with an index value
It is anticipated that "div" may be used in concert with <xref target="RF of "1.2.1", the claims set of the corresponding PASSporT with "div"
C7044">History-Info</xref> in some deployments. It may not be clear from the "or might look like:</t>
ig" and "dest" values which History-Info <sourcecode><![CDATA[
header a given PASSporT correlates to, especially because some of the tar
get changes tracked by History-Info will not be reflected in a "div" PASSporT (s
ee <xref target="intro"/>). Therefore an "hi" element as defined here may appear
in "div" corresponding to the History-Info header field index parameter value.
So for a History-Info header field with an index value of "1.2.1", the claims se
t of the corresponding PASSporT with "div" might look like:
</t>
<figure>
<artwork><![CDATA[
{ "orig":{"tn":"12155551212"}, { "orig":{"tn":"12155551212"},
"dest":{"tn":["12155551214"]}, "dest":{"tn":["12155551214"]},
"iat":1443208345, "iat":1443208345,
"div":{"tn":"121555551213", "div":{"tn":"121555551213",
"hi":"1.2.1"} } "hi":"1.2.1"} }
]]></artwork> ]]></sourcecode>
</figure> <t>Past experience has shown that there may be additional information
<t> about the motivation for retargeting, which relying parties might consider
Past experience has shown that there may be additional information about when making authorization decisions about a call; see, for example, the
the motivation for retargeting that relying parties might consider when making a "reason" associated with the SIP <xref target="RFC5806"
uthorization decisions about format="default">Diversion header field</xref>. Future extensions to
a call, see for example the "reason" associated with the SIP <xref target this specification might incorporate reasons into "div".</t>
="RFC5806">Diversion header field</xref>. Future extensions to this specificatio
n might incorporate reasons into "div".
</t>
</section>
<section anchor="Acknowledgments" title="Acknowledgments">
<t>We would like to thank Ning Zhang, Dave Hancock, Chris Wendt, Sean Turn
er, Russ Housley, Ben Campbell, Eric Burger, and Robert Sparks for contributions
to this document.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document contains actions for the IANA.</t>
<section title="JSON Web Token Claims Registrations">
<t>This specification requests that the IANA add two new claims
to the JSON Web Token Claims registry as defined in <xref target="RFC7519"/>.</t
>
<section title="'div' registration">
<t>
Claim Name: "div"
</t><t>
Claim Description: Diverted Target of a Call
</t><t>
Change Controller: IESG
</t><t>
Specification Document(s): [RFCThis]
</t>
</section>
<section title="'opt' registration">
<t>
Claim Name: "opt"
</t><t>
Claim Description: Original PASSporT (in Full Form)
</t><t>
Change Controller: IESG
</t><t>
Specification Document(s): [RFCThis]
</t>
</section>
</section>
<section title="PASSporT Type Registrations">
<t>This specification defines two new PASSporT types for the PASSport Exte
nsions Registry defined in <xref target="RFC8225"/>, which resides at https://ww
w.iana.org/assignments/passport/passport.xhtml#passport-extensions.
They are:</t>
<t><list><t>
"div" as defined in [RFCThis] <xref target="syntax"/>.
</t><t>
"div-o" as defined in [RFCThis] <xref target="divo"/>.
</t></list></t><t>
</t>
</section>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="priv" title="Privacy Considerations"> <name>IANA Considerations</name>
<section numbered="true" toc="default">
<name>JSON Web Token Claims Registrations</name>
<t>Per this specification, IANA has added two new claims to the
"JSON Web Token Claims" registry as defined in <xref target="RFC7519"
format="default"/>.</t>
<section numbered="true" toc="default">
<name>"div" registration</name>
<dl newline="false" spacing="normal">
<dt>Claim Name:</dt>
<dd>div</dd>
<dt>Claim Description:</dt>
<dd>Diverted Target of a Call</dd>
<dt>Change Controller:</dt>
<dd>IESG</dd>
<dt>Reference:</dt>
<dd>RFC 8946</dd>
</dl>
</section>
<section numbered="true" toc="default">
<name>"opt" registration</name>
<dl newline="false" spacing="normal">
<dt>Claim Name:</dt>
<dd>opt</dd>
<dt>Claim Description:</dt>
<dd>Original PASSporT (in Full Form)</dd>
<dt>Change Controller:</dt>
<dd>IESG</dd>
<dt>Reference:</dt>
<dd>RFC 8946</dd>
</dl>
</section>
</section>
<section numbered="true" toc="default">
<name>PASSporT Type Registrations</name>
<t>This specification defines two new PASSporT types for the "Personal
Assertion Token (PASSporT) Extensions" registry defined in <xref target="
RFC8225"
format="default"/>, which resides at
<eref target="https://www.iana.org/assignments/passport"
brackets="angle"/>. They are:</t>
<ul spacing="normal">
<li>"div", as defined in <xref target="syntax"
format="default"/>.</li>
<li>"div-o", as defined in <xref target="divo"
format="default"/>.</li>
</ul>
<t> <t>
There is an inherent trade-off in any mechanism that tracks in SIP signaling
how calls are routed through a network, as routing decisions
may expose policies set by users for how calls are forwarded, potentially re
vealing relationships between different identifiers representing the same user.
Note however that in ordinary operations, this information is revealed to the us
er agent service of the called party, not the calling party. It is usually the c
alled party who establishes these forwarding relationships, and if indeed some o
ther party is responsible for calls being forwarded to the called party, many ti
mes the called party should likely be entitled to information about why they are
receiving these calls. Similarly, a redirecting entity who sends a 3xx in the b
ackwards direction knowingly shares information about service logic with the cal
ler's network. However, as there may be unforeseen circumstances where the revel
ation of service logic to the called party poses a privacy risk, implementers an
d users of this or similar diversion-tracking techniques should understand the t
rade-off.
</t><t>
Furthermore, it is a general privacy risk of identity mechanisms overall th
at they do not interface well with anonymization services; the interaction of ST
IR with anonymization services is detailed in <xref target="RFC8224"/> Section 1
1. Any forwarding service that acts as an anonymizing proxy may not be able to p
rovide a secure chain of retargeting due to the obfuscation of the originating i
dentity.
</t><t>
Also see <xref target="RFC8224"/> Section 11 for further considerations o
n the privacy of using PASSporTs in SIP.
</t> </t>
</section>
</section> </section>
<section anchor="priv" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Privacy Considerations</name>
<t>This specification describes a security feature, and is primarily conce <t>There is an inherent trade-off in any mechanism that tracks, in SIP
rned with increasing security when calls are forwarded. Including information ab signaling, how calls are routed through a network, as routing decisions
out how calls were retargeted during the routing process may expose policies set by users for how calls are forwarded,
can allow downstream entities to infer particulars of the policies used potentially revealing relationships between different identifiers
to route calls through the network. However, including this information about f representing the same user. Note, however, that in ordinary operations,
orwarding is at the discretion of the retargeting entity, so this information is revealed to the user agent service of the called
if there is a requirement to keep an intermediate called number confide party, not the calling party. It is usually the called party who
ntial, no PASSporT should be created for that retargeting - the only consequence establishes these forwarding relationships, and if indeed some other
will be that downstream entities will be unable to correlate an party is responsible for calls being forwarded to the called party, many
incoming call with the original PASSporT without access to some prior k times the called party should likely be entitled to information about
nowledge of the policies that could have caused the retargeting. why they are receiving these calls. Similarly, a redirecting entity who
</t><t> sends a 3xx in the backwards direction knowingly shares information
Any extension that makes PASSporTs larger creates a potential amplifica about service logic with the caller's network. However, as there may be
tion mechanism for SIP-based DDoS attacks. Since diversion PASSporTs are created unforeseen circumstances where the revelation of service logic to the
as a part of normal forwarding activity, this risk arises at the discretion of called party poses a privacy risk, implementers and users of this or
the retargeting domain: simply using 3xx response redirections rather than retar similar diversion-tracking techniques should understand the
geting (by supplying a "div" per <xref target="redir"/>) mitigates the potential trade-off.</t>
impact. Under unusual traffic loads, even domains that might ordinarily retarge <t>Furthermore, it is a general privacy risk of identity mechanisms
t requests can switch to redirection. overall that they do not interface well with anonymization services; the
</t><t> interaction of STIR with anonymization services is detailed in <xref
SIP has an inherent capability to redirect requests, including forking target="RFC8224" sectionFormat="comma" section="11"/>. Any forwarding serv
them to multiple parties -- potentially a very large numbers of parties. The use ice
of the "div" PASSporT type does not grant any additional powers to attackers wh that acts as an anonymizing proxy may not be able to provide a secure
o hope to place bulk calls; if present, the "div" PASSporT instead identifies th chain of retargeting due to the obfuscation of the originating
e party responsible for the forwarding. As such, senders of bulk unsolicited tra identity.</t>
ffic are unlikely to find the use of "div" attractive. <t>Also see <xref target="RFC8224" sectionFormat="comma" section="11"/> fo
</t> r
further considerations on the privacy of using PASSporTs in SIP.</t>
</section>
<section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>This specification describes a security feature and is primarily
concerned with increasing security when calls are forwarded. Including
information about how calls were retargeted during the routing process
can allow downstream entities to infer particulars of the policies used
to route calls through the network. However, including this information
about forwarding is at the discretion of the retargeting entity, so if
there is a requirement to keep an intermediate called number
confidential, no PASSporT should be created for that retargeting -- the
only consequence will be that downstream entities will be unable to
correlate an incoming call with the original PASSporT without access to
some prior knowledge of the policies that could have caused the
retargeting.</t>
<t>Any extension that makes PASSporTs larger creates a potential
amplification mechanism for SIP-based DDoS attacks. Since diversion
PASSporTs are created as a part of normal forwarding activity, this risk
arises at the discretion of the retargeting domain; simply using 3xx
response redirections rather than retargeting (by supplying a "div" per
<xref target="redir" format="default"/>) mitigates the potential
impact. Under unusual traffic loads, even domains that might ordinarily
retarget requests can switch to redirection.</t>
<t>SIP has an inherent capability to redirect requests, including
forking them to multiple parties -- potentially, a very large number of
parties. The use of the "div" PASSporT type does not grant any
additional powers to attackers who hope to place bulk calls; if present,
the "div" PASSporT instead identifies the party responsible for the
forwarding. As such, senders of bulk unsolicited traffic are unlikely to
find the use of "div" attractive.</t>
</section> </section>
</middle> </middle>
<!-- *****BACK MATTER ***** --> <!-- *****BACK MATTER ***** -->
<back> <back>
<!-- References split into informative and normative -->
<!-- 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)
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")
Both are cited textually in the same manner: by using xref elements. <references>
If you use the PI option, xml2rfc will, by default, try to find included fil <name>References</name>
es in the same <references>
directory as the including file. You can also define the XML_LIBRARY environ <name>Normative References</name>
ment variable <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
with a value containing a set of directories to search. These can be either ence.RFC.2119.xml"/>
in the local <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
filing system or remote ones accessed by http (http://domain/dir/... ).--> ence.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3261.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7044.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7519.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8224.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8225.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8226.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7340.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8443.xml"/>
<references title="Normative References"> <!-- draft-ietf-stir-oob (AUTH48 as 8816) -->
&RFC2119; <reference anchor="RFC8816" target="https://www.rfc-editor.org/info/rfc8816">
&RFC8174; <front>
&RFC3261; <title>STIR Out-of-Band Architecture and Use Cases</title>
&RFC7044; <author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
&RFC7519; <organization />
&RFC8224; </author>
&RFC8225; <author initials='J' surname='Peterson' fullname='Jon Peterson'>
&RFC8226; <organization />
</references> </author>
<references title="Informative References"> <date month='February' year='2021' />
&RFC7340; </front>
&RFC8443; <seriesInfo name="RFC" value="8816"/>
&I-D.ietf-stir-oob; <seriesInfo name="DOI" value="10.17487/RFC8816"/>
</reference>
&RFC5806; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5806.xml"/>
</references>
</references> </references>
<section anchor="keys" title="Appendix A: Keys for Examples"> <section anchor="keys" numbered="true" toc="default">
<t> <name>Keys for Examples</name>
The following EC256 keys are used in the signing examples given in this <t>The following EC256 keys are used in the signing examples given in
document. WARNING: Do not use this key pair in production systems. this document. WARNING: Do not use this key pair in production
</t> systems.</t>
<figure>
<artwork><![CDATA[ <sourcecode><![CDATA[
-----BEGIN PUBLIC KEY----- -----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEmzGM1VsO+3IqbMF54rQMaYKQftO4 MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEmzGM1VsO+3IqbMF54rQMaYKQftO4
hUYm9wv5wutLgEd9FsiTy3+4+Wa2O7pffOXPC0QzO+yD8hGEXGP/2mZo6w== hUYm9wv5wutLgEd9FsiTy3+4+Wa2O7pffOXPC0QzO+yD8hGEXGP/2mZo6w==
-----END PUBLIC KEY----- -----END PUBLIC KEY-----
-----BEGIN EC PRIVATE KEY----- -----BEGIN EC PRIVATE KEY-----
MHcCAQEEIFKCsFZ4Wsw3ZpBxgc4Z0sOjaXDdMk07Ny1fKg6OntAkoAoGCCqGSM49 MHcCAQEEIFKCsFZ4Wsw3ZpBxgc4Z0sOjaXDdMk07Ny1fKg6OntAkoAoGCCqGSM49
AwEHoUQDQgAEmzGM1VsO+3IqbMF54rQMaYKQftO4hUYm9wv5wutLgEd9FsiTy3+4 AwEHoUQDQgAEmzGM1VsO+3IqbMF54rQMaYKQftO4hUYm9wv5wutLgEd9FsiTy3+4
+Wa2O7pffOXPC0QzO+yD8hGEXGP/2mZo6w== +Wa2O7pffOXPC0QzO+yD8hGEXGP/2mZo6w==
-----END EC PRIVATE KEY----- -----END EC PRIVATE KEY-----
]]></artwork> ]]></sourcecode>
</figure> </section>
</section> <section anchor="Acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>We would like to thank <contact fullname="Ning Zhang"/>, <contact
fullname="Dave Hancock"/>, <contact fullname="Chris Wendt"/>, <contact
fullname="Sean Turner"/>, <contact fullname="Russ Housley"/>, <contact
fullname="Ben Campbell"/>, <contact fullname="Eric Burger"/>, and
<contact fullname="Robert Sparks"/> for contributions to this
document.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 37 change blocks. 
838 lines changed or deleted 810 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/