<?xml version="1.0" encoding="US-ASCII"?>
<!--
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. --> encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.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/reference.I-D.ietf-stir-oob.xml">

]>
<!--?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?-->
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
    please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
    (Here they are set differently than their defaults in xml2rfc v1.32) -->
<!--?rfc strict="yes" ?-->
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
    (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="no" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions --> "rfc2629-xhtml.ent">

<rfc category="std" xmlns:xi="http://www.w3.org/2001/XInclude"
     docName="draft-ietf-stir-passport-divert-09" number="8946"
     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)" --> updates="8224" obsoletes="" submissionType="IETF"
     category="std" consensus="true" xml:lang="en" tocInclude="true"
     tocDepth="4" symRefs="true" sortRefs="true" version="3">

  <!-- ***** FRONT MATTER ***** -->

  <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 Diverted">Personal Assertion Token (PASSporT)
    Extension for Diverted Calls</title>

    <seriesInfo name="RFC" value="8946"/>
    <author initials="J." surname="Peterson" fullname="Jon Peterson">
      <organization abbrev="Neustar">Neustar, Inc.</organization>
      <address>
        <postal>
          <street>1800 Sutter St St., Suite 570</street>
          <city>Concord</city>
          <region>CA</region>
          <code>94520</code>
                    <country>US</country>
          <country>United States of America</country>
        </postal>
        <email>jon.peterson@team.neustar</email>
      </address>
    </author>

    <date year="2020" year="2021" month="February" />

    <!--    <area>
    ART
    </area>-->

    <area>ART</area>
    <workgroup>STIR</workgroup>

    <keyword>SIP</keyword>
    <keyword>STIR</keyword>
    <keyword>Identity</keyword>
    <abstract>
      <t>
	  PASSporT
      <t>The Personal Assertion Token (PASSporT) is specified in RFC 8225 to
      convey cryptographically-signed cryptographically signed
      information about the people involved in personal communications. This
      document extends PASSporT to include an indication that a call has been
      diverted from its original destination to a new one. This information
      can greatly improve the decisions made by verification services in call
      forwarding scenarios. Also specified here is an encapsulation mechanism
      for nesting a PASSporT within another PASSporT that assists relying
      parties in some diversion scenarios.
	  </t> scenarios.</t>
      <t>This document updates RFC 8224.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" title="Introduction">
	<t>
	A numbered="true" toc="default">
      <name>Introduction</name>
      <t>A Personal Assertion Token (<xref target="RFC8225">PASSporT</xref>) (PASSporT) <xref target="RFC8225"
      format="default"/> is a token format based on the JSON
      Web Token (<xref target="RFC7519">JWT</xref>) (JWT) <xref target="RFC7519" format="default"/> for
      conveying cryptographically-signed cryptographically signed information about the people involved
      in personal communications; it is used by the Secure Telephone Identity
      Revisited (<xref target="RFC8224">STIR</xref>) (STIR) protocol <xref target="RFC8224" format="default"/>
      to convey a signed assertion of the identity of the participants in
      real-time communications established via a protocol like SIP. This
      specification extends PASSporT to include an indication that a call has
      been diverted from its original destination to a new one.
	</t><t>
	Although one.</t>
      <t>Although the <xref target="RFC7340">STIR target="RFC7340" format="default">STIR problem
      statement</xref> is focused on preventing the impersonation of the
      caller's identity, which is a common enabler for threats such as
      robocalling and voicemail hacking on the telephone network today, it
      also provides a signature over the called number at the time that the
      authentication service sees it. As <xref target="RFC8224"/> Section 12.1 target="RFC8224"
      sectionFormat="comma" section="12.1"/> describes, this protection over the
      contents of the To header field is intended to prevent a class of
      cut-and-paste attacks. If Alice calls Bob, for example, Bob might
      attempt to cut-and-paste cut and paste the Identity header field in Alice's INVITE
      into a new INVITE that Bob sends to Carol, and thus be able to fool
      Carol into thinking the call came from Alice and not Bob. With the
      signature over the To header field value, the INVITE Carol sees will
      clearly have been destined originally for Bob, and thus Carol can view
      the INVITE as suspect.
		</t><t>
	However, suspect.</t>
      <t>However, as <xref target="RFC8224"/> Section 12.1.1 target="RFC8224" sectionFormat="comma" section="12.1.1"/>
      points out, it is difficult for Carol to confirm or reject these
      suspicions based on the information she receives from the baseline
      PASSporT object. The common "call forwarding" service serves as a good
      example of the reality that the original called party number is not
      always the number to which a call is delivered. There are a number of
      potential ways for intermediaries to indicate that such a forwarding
      operating has taken place. The address in the To header field value of
      SIP requests is not supposed to change, according to baseline SIP
      behavior <xref target="RFC3261"/>; target="RFC3261" format="default"/>; instead, it is the
      Request-URI that is supposed to be updated when a call is
      retargeted. Practically speaking, however, many operational environments
      do alter the To header field. The <xref target="RFC7044">History-Info target="RFC7044"
      format="default">History-Info header field</xref> was created to store
      the Request-URIs that are discarded by a call in transit. The <xref target="RFC5806">SIP
      target="RFC5806" format="default">SIP Diversion header field</xref>,
      though historic, is still used for this purpose by some operators
      today. Neither of these header fields provide any cryptographic
      assurance of secure redirection, and they both record entries for minor
      syntactical changes in URIs that do not reflect a change to the actual
      target of a call.
	</t><t>
	This call.</t>
      <t>Therefore, this specification therefore extends PASSporT with an explicit
      indication that the original called number in PASSporT no longer
      reflects the destination to which a call is intended to be
      delivered. For this purpose, it specifies a Divert PASSporT type ("div")
      for use in common SIP retargeting cases; it is expected that in this
      case, SIP INVITE requests will carry multiple Identity header fields,
      each containing its own PASSporT. Throughout this document, PASSporTs
      that contain a "div" element will be referred to as "div"
      PASSporTs. Verification services and the relying parties who make
      authorization decisions about communications may use this diversion
      indication to confirm that a legitimate retargeting of the call has
      taken place, rather than a cut-and-paste attack. For <xref target="I-D.ietf-stir-oob">out-of-band</xref>
      target="RFC8816" format="default">out-of-band use cases, 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> PASSporTs.</t>
    </section>
    <section anchor="terminology" title="Terminology">
            <t>The numbered="true" toc="default">
      <name>Terminology</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
                "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
                "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as
    described in
                BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
    </section>
    <section anchor="syntax" title="The 'div' numbered="true" toc="default">
      <name>The "div" PASSporT Type and Claim">
      <t>
	  This Claim</name>
      <t>This specification defines a <xref target="RFC8225">PASSporT</xref> target="RFC8225"
      format="default">PASSporT</xref> type called "div" that "div", which may be employed
      by authentication services located at retargeting entities. All "div"
      PASSporTs MUST <bcp14>MUST</bcp14> contain a new JSON Web Token "div" claim, also specified
      in this document, which indicates a previous destination for a call
      during its routing process. When a retargeting entity receives a call
      signed with a PASSporT, it may act as an authentication service and
      create a new PASSporT containing the "div" claim to attach to the call.
	</t><t>
Note
      call.</t>
      <t>Note that a new PASSporT is only necessary when the canonical form of
      the "dest" identifier (per the canonicalization procedures in <xref target="RFC8224"/> Section 8.3)
      target="RFC8224" sectionFormat="comma" section="8.3"/>) changes due to this
      retargeting. If the canonical form of the "dest" identifier is not
      changed during retargeting, then a new PASSporT with a "div" claim MUST NOT <bcp14>MUST
      NOT</bcp14> be produced.
	</t><t>
The produced.</t>
      <t>The headers of the new PASSporTs generated by retargeting entities MUST
      <bcp14>MUST</bcp14> include the "div" PASSporT
		type, type and an "x5u" field pointing to a
      credential that the retargeting entity controls. "div" PASSporTs MUST <bcp14>MUST</bcp14>
      use full form instead of compact form. The new PASSporT header will look
      as follows:
	  </t>
	  	   <figure>
       <artwork><![CDATA[ follows:</t>
<sourcecode><![CDATA[
{ "typ":"passport",
  "ppt":"div",
  "alg":"ES256",
  "x5u":"https://www.example.com/cert.cer" }
		]]></artwork>
      </figure>
	  <t>
	  A
]]></sourcecode>
      <t>A "div" PASSporT claims set is populated with elements drawn from the
      PASSporT(s) received for a call by the retargeting entity: entity; at a high
      level, the original identifier for the called party in the "dest" object
      will become the "div" claim in the new PASSporT. If the "dest" object of
      the original PASSporT contains multiple identifiers, because it contains
      one or more name/value pairs with an array as its value, the retargeting
      entity MUST <bcp14>MUST</bcp14> select only one identifier from the value(s) of the "dest"
      object to occupy the value of the "div" field in the new
      PASSporT. Moreover, it MUST <bcp14>MUST</bcp14> select an identifier that is within the
      scope of the credential that the retargeting entity will specify in the
      "x5u" of the PASSporT header (as described below).
	  </t><t>
	  The below).</t>
      <t>The new target for the call selected by the retargeting entity
      becomes the value of the "dest" object of the new PASSporT. The "orig"
      object MUST <bcp14>MUST</bcp14> be copied into the new PASSporT from the original PASSporT
      received by the retargeting entity. The retargeting entity SHOULD <bcp14>SHOULD</bcp14> retain
      the "iat" object from the original PASSporT, though if in the underlying
      signaling protocol  (e.g.  (e.g., SIP) the retargeting entity changes the date
      and time information in the retargeted request, the new PASSporT should
      instead reflect that date and time. No other claims or extensions are to
      be copied from the original PASSporT to the "div" PASSporT.
	  </t><t>So, PASSporT.</t>
      <t>So, for an original PASSporT claims set of the form:
	  </t>
	  	  	<figure>
        <artwork><![CDATA[ form:</t>
<sourcecode><![CDATA[
   { "dest":{"tn":["12155551213"]},
     "iat":1443208345,
     "orig":{"tn":"12155551212"} }
		]]></artwork>
      </figure>
]]></sourcecode>
      <t>If the retargeting entity is changing the target from 12155551213 to
      12155551214, the claims set of a "div" PASSpoRT PASSporT generated by the
      retargeting entity would look as follows:</t>
	  	<figure>
        <artwork><![CDATA[
<sourcecode><![CDATA[
   { "dest":{"tn":["12155551214"]},
     "div":{"tn":"121555551213"},
     "iat":1443208345,
     "orig":{"tn":"12155551212"} }
		]]></artwork>
      </figure>
	  <t>
	  The
]]></sourcecode>
      <t>The combined full form PASSporT (with a signature covered by the
      ES256 keys given in <xref target="keys"/>) target="keys" format="default"/>) would look
      as follows:
	  	  </t>
	  	<figure>
        <artwork><![CDATA[ follows:</t>
<sourcecode><![CDATA[
eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdiIsInR5cCI6InBhc3Nwb3J0IiwieDV1Ij \
oiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQ.eyJkZXN0Ijp7InRuI \
jpbIjEyMTU1NTUxMjE0Il19LCJkaXYiOnsidG4iOiIxMjE1NTU1NTEyMTMifSwiaWF \
0IjoxNDQzMjA4MzQ1LCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.xBHWipDEE \
J8a6TsdX6xUXAnblsFiGUiAxwLiv0HLC9IICj6eG9jQd6WzeSSjHRBwxmChHhVIiMT \
SqIlk3yCNkg
	  		]]></artwork>
      </figure>
	  <t>
	  The
]]></sourcecode>
      <t>The same "div" PASSporT would result if the "dest" object of the
      original PASSporT contained an array value, such as
      {"tn":["12155551213","19995551234"]}, and the retargeting entity chose
      to retarget from the first telephone number in the array. Every "div"
      PASSporT is diverting from only one identifier.
	  </t><t>
	  Note identifier.</t>
      <t>Note that the "div" element may contain other name/value pairs than
      just a destination, including a History-Info indicator (see <xref target="hi"/>).
      target="hi" format="default"/>). After the PASSporT header and claims
      have been constructed, their signature is generated per the guidance in
      <xref target="RFC8225"/> - target="RFC8225" format="default"/> -- except for the credential
      required to sign it. While in the ordinary construction of a PASSporT,
      the credential used to sign will have authority over the identity in the
      "orig" claim (for example, a certificate with authority over the
      telephone number in "orig" per <xref target="RFC8226"/>), target="RFC8226"
      format="default"/>), for all PASSporTs using the "div" type the
      signature MUST <bcp14>MUST</bcp14> be created with a credential with authority over the
      identity present in the "div" claim. So for the example above, where the
      original "dest" is "12155551213", the signer of the new PASSporT object MUST
      <bcp14>MUST</bcp14> have authority over that telephone number, number and need not have any
      authority over the telephone number present in the "orig" claim.
	  </t><t>
	 Note claim.</t>
      <t>Note that Identity header fields are not ordered in a SIP request,
      and in a case where there is a multiplicity of Identity header fields in
      a request, some sorting may be required to match "div" PASSporTs to
      their originals.
	 	  </t><t>
	 PASSporTs originals.</t>
      <t>PASSporTs of type "div" MUST NOT <bcp14>MUST NOT</bcp14> contain an "opt" (see <xref target="opt"/>)
      target="opt" format="default"/>) element in their payload.
	  </t> payload.</t>
    </section>
    <section anchor="use" title="Using 'div' numbered="true" toc="default">
      <name>Using "div" in SIP">
      <t>
	  This 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> claim.</t>
      <section anchor="as" title="Authentication numbered="true" toc="default">
        <name>Authentication Service Behavior">
		<t>
		An 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 MUST NOT <bcp14>MUST NOT</bcp14> add a
	"div" PASSporT to an INVITE that contains no Identity header
	field. The retargeting entity SHOULD <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 MUST NOT <bcp14>MUST NOT</bcp14> remove the
	original request's Identity header field value before forwarding.
		</t><t>
		As forwarding.</t>
        <t>As was stated in <xref target="syntax"/>, target="syntax" format="default"/>, the
	authentication service MUST <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 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"/>. 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 PASSporT.</t>
        <t>When adding an Identity header field with a PASSporT claims set
	containing a "div" claim, SIP authentication services MUST <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"/>, target="syntax" format="default"/>,
	the new Identity header added after retargeting might look as follows:
	  	  	</t>
	  	<figure>
        <artwork>
		<![CDATA[
	follows:</t>
<sourcecode><![CDATA[
Identity:eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdiIsInR5cCI6InBhc3Nwb3J0I \
iwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQ.eyJkZXN0 \
Ijp7InRuIjpbIjEyMTU1NTUxMjE0Il19LCJkaXYiOnsidG4iOiIxMjE1NTU1NTEyMT \
MifSwiaWF0IjoxNDQzMjA4MzQ1LCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0. \
xBHWipDEEJ8a6TsdX6xUXAnblsFiGUiAxwLiv0HLC9IICj6eG9jQd6WzeSSjHRBwxm \
ChHhVIiMTSqIlk3yCNkg; \
info=<https://www.example.com/cert.cer>;ppt="div"
	  		]]>
	  </artwork>
      </figure>
	<t>
	Note
]]></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 contain, in different Identity
	header fields fields, a baseline <xref target="RFC8224"/> target="RFC8224" format="default"/>
	PASSporT and a PASSporT of type <xref target="RFC8443">"rph"</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 SHOULD <bcp14>SHOULD</bcp14> generate only one
	"div" PASSporT. If the "orig" or "dest" of these PASSporTs differ,
	however, one "div" PASSporT SHOULD <bcp14>SHOULD</bcp14> be generated for each non-"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, services.</t>
        <t>Furthermore, a request may also be retargeted a second time, at
	which point the subsequent retargeting entity SHOULD <bcp14>SHOULD</bcp14> generate one
	"div" PASSporT for each previous "div" PASSporT in the request which 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 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> values.</t>
      </section>
      <section anchor="vs" title="Verification numbered="true" toc="default">
        <name>Verification Service Behavior">
		<t>
	  <xref target="RFC8224"/> Section 6.2 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 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 MUST <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", "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 MAY <bcp14>MAY</bcp14> still validate any non-"div"
        PASSporTs in the request per the normal procedures in <xref target="RFC8224"/> procedures.
        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,
        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"/> Section 6.2.1, 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 specification.</t>
        <t>A verification service parses a chain of PASSporTs as follows:
	</t>
	<t><list><t>
	First, the follows:</t>

        <ol type="1">
          <li>The verification service MUST <bcp14>MUST</bcp14> compare the value in the
	  outermost "dest" field to the target of the call. As it is
	  anticipated that SIP authentication services that create "div"
	  PASSporTs will populate the "dest" header from the retargeted
	  Request-URI (see <xref target="as"/>), target="as" format="default"/>), in ordinary
	  SIP operations, the Request-URI is where verification services will
	  find the latest call target. Note however Note, however, that after a "div"
	  PASSporT has been added to a SIP request, the Request-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
	  verification service MAY <bcp14>MAY</bcp14> compare the "dest" field to a provisioned
	  telephone number for the recipient.
	  	 </t><t>
	Second, the recipient.</li>
          <li>The verification service MUST <bcp14>MUST</bcp14> validate the signature
	  over the outermost "div" PASSporT, 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"/> Section 6.2
	  target="RFC8224" sectionFormat="comma" section="6.2"/>, Step 3).
		 </t><t>
	Third, the 3).</li>
          <li>The verification service MUST <bcp14>MUST</bcp14> validate that the "orig"
	  field of the innermost PASSporT of the chain (the only PASSporT in
	  the chain which 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 MUST <bcp14>MUST</bcp14> treat the entire PASSporT
	  chain as invalid. The verification service MUST <bcp14>MUST</bcp14> also
	  verify that all other "div" PASSporTs in the chain share the same
	  "orig" value. Then Then, the verification service validates the
	  relationship of the "orig" field to the SIP-level call signaling per
	  the guidance in <xref target="RFC8224"/> Section 6.2 target="RFC8224" sectionFormat="comma"
	  section="6.2"/>, Step 2.
		 </t><t>
	Fourth, the 2.</li>
          <li>The verification service MUST <bcp14>MUST</bcp14> check the date freshness
	  in the outermost "div" PASSporT PASSporT, per <xref target="RFC8224"/> Section 6.2 target="RFC8224"
	  sectionFormat="comma" section="6.2"/>, Step 4. It Furthermore, it is furthermore RECOMMENDED <bcp14>RECOMMENDED</bcp14>
	  that the verification service check that the "iat" field of the
	  innermost PASSporT is also within the date freshness interval; otherwise
	  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).
		 </t><t>
             Fifth, the suffice).</li>
          <li>The verification service MUST <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"/>) 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"/> Section 6.2 target="RFC8224" sectionFormat="comma" section="6.2"/>, Step 1 applies
	  to the chain validation process: process; if the innermost PASSporT contains
	  an unsupported "ppt", its chain MUST <bcp14>MUST</bcp14> be ignored.
	</t></list></t>
	<t>
	Note ignored.</li>
        </ol>
        <t>Note that the To header field is not used in the first step
	above. Optionally, the verification service MAY <bcp14>MAY</bcp14> verify that 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> redirection.</t>
      </section>
    </section>
    <section anchor="divo" title="The 'div-o' numbered="true" toc="default">
      <name>The "div-o" PASSporT Type">
	  <t>
	  This Type</name>
      <t>This specification defines a "div-o" PASSporT type that uses the
      "div" claim element in conjunction with the <xref target="opt">"opt"</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" extension
      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="I-D.ietf-stir-oob">out-of-band</xref> target="RFC8816"
      format="default">out-of-band STIR scenarios.
	  </t><t>
	  The 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>
	  	   <figure>
       <artwork><![CDATA[ follows:</t>
<sourcecode><![CDATA[
{ "typ":"passport",
  "ppt":"div-o",
  "alg":"ES256",
  "x5u":"https://www.example.com/cert.cer" }
		]]></artwork>
      </figure>
	  <t>
	  Whereas
]]></sourcecode>
      <t>Whereas a "div" PASSporT claims set contains only the "orig", "dest",
      "iat", and "div" elements, the "div-o" additionally MUST <bcp14>MUST</bcp14> contain an
      "opt" element (see <xref target="opt"/>), target="opt" format="default"/>), which
      encapsulates the full form of the previous PASSporT from which the call
      was retargeted, triggering the generation of this "div-o". The format of
      the "opt" element is identical to the encoded PASSporT format given in Appendix A of
      <xref target="RFC8225"/>.
	  </t><t>So, target="RFC8225" sectionFormat="of" section="A"/>.</t>
      <t>So, for an original PASSporT claims set of the form:
	  </t>
	  	  	<figure>
        <artwork><![CDATA[ form:</t>
<sourcecode><![CDATA[
   { "orig":{"tn":"12155551212"},
     "dest":{"tn":["12155551213"]},
     "iat":1443208345 }
		]]></artwork>
      </figure>
]]></sourcecode>
      <t>If the retargeting entity is changing the target from 12155551213 to
      12155551214, the new PASSporT claims set for "div-o" would look as
      follows:</t>
	  	<figure>
        <artwork><![CDATA[
<sourcecode><![CDATA[
 { "orig":{"tn":"12155551212"},
   "dest":{"tn":["12155551214"]},
   "iat":1443208345,
   "div":{"tn":"121555551213"},
   "opt":"eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0c \
   HM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQ.eyJkZXN0Ijp7InRuIjpbIj \
   EyMTU1NTUxMjEzIl19LCJpYXQiOjE0NDMyMDgzNDUsIm9yaWciOnsidG4iOiIxMj \
   E1NTU1MTIxMiJ9fQ.1bEzkzcNbKvgz4QoMx0_DJ2T8qFMDC1sPqHPXl1WvbauzRJ \
   RvYlZqQ0qgGTlS8tJ_wXjVe07Z3wvDrdApHhhYw" }
		]]></artwork>
      </figure>
	  <t>
	  While
]]></sourcecode>
      <t>While in ordinary operations, it is not expected that SIP would carry
      a "div-o" PASSporT, it might be possible in some gatewaying
      scenarios. The resulting full form Identity header field with a "div-o"
      PASSporT would look as follows:
	  </t>
	  	<figure>
        <artwork><![CDATA[ follows:</t>
<sourcecode><![CDATA[
Identity:eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdi1vIiwidHlwIjoicGFzc3Bvc \
nQiLCJ4NXUiOiJodHRwczovL3d3dy5leGFtcGxlLmNvbS9jZXJ0LmNlciJ9.eyJkZX \
N0Ijp7InRuIjoiMTIxNTU1NTEyMTQifSwiZGl2Ijp7InRuIjoiMTIxNTU1NTUxMjEz \
In0sImlhdCI6MTQ0MzIwODM0NSwib3B0IjoiZXlKaGJHY2lPaUpGVXpJMU5pSXNJbl \
I1Y0NJNkluQmhjM053YjNKMElpd2llRFYxSWpvaWFIUjBjSE02THk5M2QzY3VaWGho \
YlhCc1pTNWpiMjB2WTJWeWRDNWpaWElpZlEuZXlKa1pYTjBJanA3SW5SdUlqcGJJak \
V5TVRVMU5UVXhNakV6SWwxOUxDSnBZWFFpT2pFME5ETXlNRGd6TkRVc0ltOXlhV2Np \
T25zaWRHNGlPaUl4TWpFMU5UVTFNVEl4TWlKOWZRLjFiRXpremNOYkt2Z3o0UW9NeD \
BfREoyVDhxRk1EQzFzUHFIUFhsMVd2YmF1elJKUnZZbFpxUTBxZ0dUbFM4dEpfd1hq \
VmUwN1ozd3ZEcmRBcEhoaFl3Iiwib3JpZyI6eyJ0biI6IjEyMTU1NTUxMjEyIn19.C \
HeA9wRnthl7paMe6rP0TARpmFCXjmi_vF_HRz2O_oulB_R-G9xZNiLVvmvHv4gk6LI \
LaDV2y2VtHTLIEgmHig; \
info=<https://www.example.com/cert.cer>;ppt="div-o"
	  		]]></artwork>
      </figure>
]]></sourcecode>
      <section anchor="optasvs" title="Processing 'div-o' PASSporTs">
     <t>
	 The numbered="true" toc="default">
        <name>Processing "div-o" PASSporTs</name>
        <t>The authentication and verification service procedures required for
	"div-o" closely follow the guidance given in Sections <xref target="as"/> target="as"
	format="counter"/> and <xref target="vs"/>, target="vs" format="counter"/>, with the
	major caveats being being, first, that they do store or retrieve PASSporTs
	via the Identity header field values of SIP requests, and requests and, second, that
	they process nested PASSporTs in the "opt" claim element. But
	transposing the rest of the behaviors described above to creating and
	validating "div-o" PASSporTs is straightforward.
	 	  	 </t><t>
	 For straightforward.</t>
        <t>For the "div-o" PASSporT type, retargeting authentication services
	that handle calls with one or more existing PASSporTs will create a
	corresponding "div-o" PASSporT for each received PASSporT. Each
	"div-o" PASSporT
	  MUST <bcp14>MUST</bcp14> contain an "opt" claim set
	element with the value of the original PASSporT from which the "div-o"
	was created; and as specified in <xref target="as"/>, target="as"
	format="default"/>, the authentication service MUST <bcp14>MUST</bcp14>
	populate the "div" claim set element of the "div-o" PASSporT with the
	"dest" field fo of the original PASSporT. Each received PASSporT may in
	turn contain its own "opt" claim set element, element if the retargeting
	authentication service is not the first in its chain. Note that if the
	retargeting authentication service is handling a call with multiple
	PASSporTs, which in ordinary SIP operation would result in the
	construction of multiple "div" chains, it will in effect be generating
	one "div-o" PASSporT per chain.
	 	 	 </t><t>
	The chain.</t>
        <t>The job of a verification service is in many ways easier for
	"div-o" than for "div", as the verification service has no need to
	correlate the PASSporTs it receives and assemble them into chains, as
	any chains in "div-o" will be nested through the "opt"
	element. Nonetheless, the verification services MUST <bcp14>MUST</bcp14> perform the same
	chain validation described in <xref target="vs"/> target="vs" format="default"/> to
	validate that each nested PASSporT shares the same "orig" field as its
	enclosing PASSporT, PASSporT and that the "dest" field of each nested PASSporT
	corresponds to the "div" field of its enclosing PASSporT. The same
	checks MUST <bcp14>MUST</bcp14> also be performed for freshness, signature validation, and
	so on. It is similarly OPTIONAL <bcp14>OPTIONAL</bcp14> for the verification service to
	determine that the "dest" claims element of the outermost PASSporT
	corresponds to the called party indication of receive telephone
	signaling, where such indication would vary depending on the using
	protocol.
	 	 	 </t><t>
    How </t>
        <t>How authentication services or verification services receive or
	transport PASSporTs for "div-o" is outside the scope of this document, document
	and dependent on the using protocol.
	 </t> protocol.</t>
      </section>
    </section>
    <section anchor="opt" title="Definition numbered="true" toc="default">
      <name>Definition of 'opt'">
    <t>
	The "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" "opt", as defined
      in this specification specification, may be used by future PASSporT extensions as well
      as in conjunction with "div-o".
	</t><t>
	"opt" MUST "div-o".</t>
      <t>"opt" <bcp14>MUST</bcp14> contain a quoted full-form PASSporT PASSporT, as
      specified by <xref target="RFC8225"/> Appendix A; target="RFC8225" sectionFormat="comma" section="A"/>; it MUST NOT
      <bcp14>MUST NOT</bcp14> contain a compact form PASSporT. For an example
      of a "div-o" PASSporT containing "opt," "opt", see <xref target="divo"/>.
	</t> target="divo"
      format="default"/>.</t>
    </section>

    <section anchor="redir" title="'div' numbered="true" toc="default">
      <name>"div" and Redirection">
    <t>
	The Redirection</name>
      <t>The "div" mechanism exists primarily to prevent false negatives at
      verification services when an arriving SIP request, due to intermediary
      retargeting, does not appear to be intended for its eventual recipient,
      because the original PASSporT "dest" value designates a different destination.
	</t><t>
	Any
      destination.</t>
      <t>Any intermediary that assigns a new target to a request can, instead
      of retargeting and forwarding the request, instead redirect with a 3xx
      response code. In ordinary operations, a redirection poses no
      difficulties for the operations of baseline STIR: when the user agent
      client (UAC) receives the 3xx response, it will initiate a new request
      to the new target (typically  the target carried in the Contact header
      field value of the 3xx), and the "dest" of the PASSporT created for the
      new request will match that new target. As no impersonation attack can
      arise from this case, it creates no new requirements for STIR.
	</t><t>
	However, STIR.</t>
      <t>However, some UACs record the original target of a call with
      mechanisms like <xref target="RFC7044">History-Info</xref> target="RFC7044"
      format="default">History-Info</xref> or <xref target="RFC5806">Diversion</xref>, target="RFC5806"
      format="default">Diversion</xref> and may want to leverage STIR to
      demonstrate to the ultimate recipient that the call has been redirected securely:
      securely, that is, that the original destination was the one that sent
      the redirection message that led to the recipient receiving the
      request. The semantics of the PASSporT necessary for that assertion are
      the same as those for the "div" retargeting cases above. The only
      wrinkle is that the PASSporT needs to be generated by the redirecting
      entity and sent back to the originating user agent client within the 3xx response.
	</t><t>
    This
      response.</t>
      <t>This introduces more complexity than might immediately be
      apparent. In the first place, a 3xx response can convey multiple targets
      through the Contact header field value; to accommodate this, the "div"
      PASSporT MAY <bcp14>MAY</bcp14> include one "dest" object array value per Contact, but if
      the retargeting entity wants to keep the Contact list private from
      targets, it may need to generate one PASSporT per Contact. Bear in mind
      as well that the original SIP request could have carried multiple
      Identity header field values that had been added by different
      authentication services in the request path, so a redirecting entity
      might need to generate one "div" PASSporT for each PASSporT in the
      original request. Often, this will mean just one "div" PASSporT, but for
      some deployment scenarios, it could require an impractical number of
      combinations. But in very complex call routing scenarios, attestation of
      source identity would only add limited value anyway.
	</t><t> anyway.</t>
      <t>Therefore, STIR-aware SIP intermediaries that redirect requests MAY therefore
      <bcp14>MAY</bcp14> convey one or more PASSporTs in the
      backwards direction within Identity header fields. These redirecting
      entities will act as authentication services for "div" as described in
      <xref target="as"/>. target="as" format="default"/>. This document consequently updates
      <xref target="RFC8224"/> target="RFC8224" format="default"/> to permit carrying Identity
      header fields in SIP 300-class responses. It is left to the originating
      user agent to determine which Identity header fields should be copied
      from the 3xx into any new requests resulting from the redirection, if any:
      any; use of these Identity header fields by entities receiving a 3xx
      response is OPTIONAL.
	</t><t>
	Finally, <bcp14>OPTIONAL</bcp14>.</t>
      <t>Finally, note that if an intermediary in the response path consumes
      the 3xx and explores new targets itself while performing sequential
      forking, it will effectively retarget the call on behalf of the
      redirecting server, and this will create the same need for "div"
      PASSporTs as any other retargeted call. These intermediaries MAY <bcp14>MAY</bcp14> also
      copy PASSporTs from the 3xx response and insert them into sequential
      forking requests, if appropriate.
	</t> appropriate.</t>
    </section>
    <section anchor="hi" title="Extending 'div' numbered="true" toc="default">
      <name>Extending "div" to work Work with Service Logic Tracking">
    <t>
	It Tracking</name>
      <t>It is anticipated that "div" may be used in concert with <xref target="RFC7044">History-Info</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"/>). Therefore target="intro"
      format="default"/>).

      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 set of the corresponding PASSporT with "div"
      might look like:
	</t>
	  <figure>
        <artwork><![CDATA[ like:</t>
<sourcecode><![CDATA[
   { "orig":{"tn":"12155551212"},
     "dest":{"tn":["12155551214"]},
     "iat":1443208345,
     "div":{"tn":"121555551213",
            "hi":"1.2.1"} }
		]]></artwork>
      </figure>
	<t>
	Past
]]></sourcecode>
      <t>Past experience has shown that there may be additional information
      about the motivation for retargeting that retargeting, which relying parties might consider
      when making authorization decisions about a call, see call; see, for example example, the
      "reason" associated with the SIP <xref target="RFC5806">Diversion target="RFC5806"
      format="default">Diversion header field</xref>. Future extensions to
      this specification 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 Turner, Russ Housley, Ben Campbell, Eric Burger, and Robert Sparks for contributions to this document.</t> "div".</t>
    </section>
    <section anchor="IANA" title="IANA Considerations">
        <t>This document contains actions for the IANA.</t> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section title="JSON numbered="true" toc="default">
        <name>JSON Web Token Claims Registrations">
                <t>This specification requests that the Registrations</name>
        <t>Per this specification, IANA add has added two new claims to the JSON
	"JSON Web Token Claims Claims" registry as defined in <xref target="RFC7519"/>.</t> target="RFC7519"
	format="default"/>.</t>
        <section  title="'div' registration">
	  <t>
	  Claim Name: "div"
	  </t><t>
	 Claim Description: Diverted 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
	</t><t>
	 Change Controller: IESG
	 </t><t>
	 Specification Document(s): [RFCThis]
	  </t> Call</dd>
	    <dt>Change Controller:</dt>
	    <dd>IESG</dd>
	    <dt>Reference:</dt>
	    <dd>RFC 8946</dd>
	  </dl>
        </section>
        <section title="'opt' registration">
	<t>
	  Claim Name: "opt"
	  </t><t>
	 Claim Description: Original 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)
	</t><t>
	 Change Controller: IESG
	 </t><t>
	 Specification Document(s): [RFCThis]
	  </t> Form)</dd>
	    <dt>Change Controller:</dt>
	    <dd>IESG</dd>
	    <dt>Reference:</dt>
	    <dd>RFC 8946</dd>
          </dl>
        </section>
      </section>
      <section  title="PASSporT numbered="true" toc="default">
        <name>PASSporT Type Registrations"> Registrations</name>
        <t>This specification defines two new PASSporT types for the PASSport Extensions Registry "Personal
	Assertion Token (PASSporT) Extensions" registry defined in <xref target="RFC8225"/>, target="RFC8225"
	format="default"/>, which resides at https://www.iana.org/assignments/passport/passport.xhtml#passport-extensions.
	<eref target="https://www.iana.org/assignments/passport"
	    brackets="angle"/>. They are:</t>
	  <t><list><t>
	  "div"
        <ul spacing="normal">
          <li>"div", as defined in [RFCThis] <xref target="syntax"/>.
	  </t><t>
	  "div-o" target="syntax"
	  format="default"/>.</li>
          <li>"div-o", as defined in [RFCThis] <xref target="divo"/>.
	  </t></list></t><t> target="divo"
	  format="default"/>.</li>
        </ul>
        <t>
        </t>
      </section>
    </section>
    <section anchor="priv" title="Privacy Considerations">
        <t>
    There numbered="true" toc="default">
      <name>Privacy Considerations</name>
      <t>There is an inherent trade-off in any mechanism that tracks tracks, in SIP signaling
      signaling, how calls are routed through a network, as routing decisions
      may expose policies set by users for how calls are forwarded,
      potentially revealing relationships between different identifiers
      representing the same user. Note however Note, however, that in ordinary operations,
      this information is revealed to the user agent service of the called
      party, not the calling party. It is usually the called party who
      establishes these forwarding relationships, and if indeed some other
      party is responsible for calls being forwarded to the called party, many
      times 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 backwards direction knowingly shares information
      about service logic with the caller's network. However, as there may be
      unforeseen circumstances where the revelation of service logic to the
      called party poses a privacy risk, implementers and users of this or
      similar diversion-tracking techniques should understand the trade-off.
        </t><t>
     Furthermore,
      trade-off.</t>
      <t>Furthermore, it is a general privacy risk of identity mechanisms
      overall that they do not interface well with anonymization services; the
      interaction of STIR with anonymization services is detailed in <xref target="RFC8224"/> Section 11.
      target="RFC8224" sectionFormat="comma" section="11"/>. Any forwarding service
      that acts as an anonymizing proxy may not be able to provide a secure
      chain of retargeting due to the obfuscation of the originating identity.
	    </t><t>
	Also
      identity.</t>
      <t>Also see <xref target="RFC8224"/> Section 11 target="RFC8224" sectionFormat="comma" section="11"/> for
      further considerations on the privacy of using PASSporTs in SIP.
        </t> SIP.</t>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This specification describes a security feature, 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
      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: domain; simply using 3xx
      response redirections rather than retargeting (by supplying a "div" per
      <xref target="redir"/>) 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 redirection.</t>
      <t>SIP has an inherent capability to redirect requests, including
      forking them to multiple parties -- potentially potentially, a very large numbers 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> attractive.</t>
    </section>
  </middle>
  <!--  *****BACK MATTER ***** -->

  <back>

	<references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7044.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8224.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8225.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8226.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7340.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8443.xml"/>

<!-- References split into informative and normative draft-ietf-stir-oob (AUTH48 as 8816) -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
    1. define an ENTITY at the top,
<reference anchor="RFC8816" target="https://www.rfc-editor.org/info/rfc8816">
<front>
<title>STIR Out-of-Band Architecture 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.xml")

    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 files in the same
    directory as the including file. You can also define the XML_LIBRARY environment variable
    with a value containing a set of directories to search.  These can be either in the local
    filing system or remote ones accessed by http (http://domain/dir/... ).-->

	<references title="Normative References">
	&RFC2119;
    &RFC8174;
&RFC3261;
&RFC7044;
&RFC7519;
&RFC8224;
&RFC8225;
&RFC8226; Use Cases</title>
<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
    <organization />
</author>
<author initials='J' surname='Peterson' fullname='Jon Peterson'>
    <organization />
</author>
<date month='February' year='2021' />

</front>
<seriesInfo name="RFC" value="8816"/>
<seriesInfo name="DOI" value="10.17487/RFC8816"/>
</reference>

        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5806.xml"/>
      </references>
    <references title="Informative References">

&RFC7340;
&RFC8443;
&I-D.ietf-stir-oob;

  &RFC5806;
    </references>
    <section anchor="keys" title="Appendix A: Keys numbered="true" toc="default">
      <name>Keys for Examples">
	<t>
        The Examples</name>
      <t>The following EC256 keys are used in the signing examples given in
      this document. WARNING: Do not use this key pair in production systems.
	</t>
	  	  	<figure>
        <artwork><![CDATA[
      systems.</t>

<sourcecode><![CDATA[
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEmzGM1VsO+3IqbMF54rQMaYKQftO4
hUYm9wv5wutLgEd9FsiTy3+4+Wa2O7pffOXPC0QzO+yD8hGEXGP/2mZo6w==
-----END PUBLIC KEY-----

-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIFKCsFZ4Wsw3ZpBxgc4Z0sOjaXDdMk07Ny1fKg6OntAkoAoGCCqGSM49
AwEHoUQDQgAEmzGM1VsO+3IqbMF54rQMaYKQftO4hUYm9wv5wutLgEd9FsiTy3+4
+Wa2O7pffOXPC0QzO+yD8hGEXGP/2mZo6w==
-----END EC PRIVATE KEY-----
		]]></artwork>
      </figure>
]]></sourcecode>
    </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>
</rfc>