<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.16 (Ruby 2.6.0) -->

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-stir-identity-header-errors-handling-08" number="9410" submissionType="IETF" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true"> symRefs="true" updates="" obsoletes="" xml:lang="en" version="3">

  <!-- xml2rfc v2v3 conversion 3.17.0 -->
  <front>
    <title abbrev="Identity Errors">Identity Header Errors Handling for STIR</title> STIR">Handling of Identity Header Errors for Secure Telephone Identity Revisited (STIR)</title>
    <seriesInfo name="RFC" value="9410"/>
    <author initials="C." surname="Wendt" fullname="Chris Wendt">
      <organization>Somos Inc.</organization>
      <address>
        <email>chris-ietf@chriswendt.net</email>
      </address>
    </author>
    <date year="2023" month="February" day="25"/>

    <area>ART</area>
    <workgroup>STIR Working Group</workgroup> month="July"/>
    <area>art</area>
    <workgroup>stir</workgroup>
    <keyword>Identity</keyword>
    <keyword>multiple errors</keyword>
    <keyword>passport</keyword>
    <keyword>reason header field</keyword>
    <abstract>
      <t>This document extends STIR the current error-handling procedures for mapping of
verification failure reasons to 4xx codes for Secure Telephone Identity Revisited (STIR)
and the Authenticated Identity Management in the Session Initiation
Protocol (SIP) error handling procedures to include (SIP).
It extends the mapping of verification failure reasons ability to STIR defined 4xx codes so use the failure reason of Reason header field as an option for conveying
an error associated with an Identity header field can be conveyed to the upstream
authentication service when local policy dictates that the call
should continue in the presence of a verification failure.
This document also defines procedures that enable a failure reason to be mapped to a specific Identity header field for scenarios that use multiple Identity header fields fields, where some may have errors and others may not and the not. The handling of those situations is also defined.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction"><name>Introduction</name> anchor="introduction">
      <name>Introduction</name>
      <t>The STIR framework as described in <xref target="RFC7340"/> is an authentication framework for asserting a telephone number or URI based URI-based identity using a digital signature and certificate based framework certificate-based framework, as described in <xref target="RFC8225"/> and <xref target="RFC8226"/> target="RFC8226"/>, respectively.
<xref target="RFC8224"/> describes the use of the STIR framework in the SIP protocol <xref target="RFC3261"/> and target="RFC3261"/>. It defines both a) the authentication service that creates a PASSporT, defined in PASSporT <xref target="RFC8225"/>, target="RFC8225"/> and delivers it in an Identity header field field, and b) the verification service that correspondingly verifies the PASSporT and embedded originating identity.</t>
      <t>This document is concerned with errors in validating PASSporTs and Identity header fields and how they are communicated in special cases and cases. This document also defines a solution to help address the potential issue of multiple Identity header fields and the plurality of potential verification errors.
Additionally, it addresses the issue of the current 4xx error response and that when there response, i.e., the call is terminated when a verification error, the call error is terminated. present. In some deployments, it may be the case that the policy for handling errors dictates that calls should continue even if there is a verification error. In
For example, in many cases of, for example, of inadvertent or operational errors that do not represent any identity falsification type of identity falsification attempt, the preferred policy of continuing the call even though the identity is not verified, may be to continue the preferred policy. call despite the unverified identity. In these cases, the authentication service should still be notified of the error so that corrective action can be taken to fix any issues. This specification will discuss the use of the Reason header field in subsequent provisional (1xx) responses in order to deliver the error back to the authentication service or other SIP path network equipment responsible for error handling.</t>

<t>For the handling of
      <t>To handle multiple Identity header fields and the potential situation that where
 some of the Identity header fields in a call may pass verification but be verified while others may not (i.e., they have errors,
 errors), this document defines the a method of adding by which an identifier is added
 to the header so that the authentication service can uniquely identify
 which Identity header field is being referred to in
 the case of an error.</t>
    </section>
    <section anchor="terminology"><name>Terminology</name>

<t>The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", anchor="terminology">
      <name>Terminology</name>
        <t>
    The key words "<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="reason-header-field-protocol-stir"><name>Reason header field protocol anchor="reason-header-field-protocol-stir">
      <name>Reason Header Field Protocol "STIR"</name>

      <t>This document defines a new Reason header field <xref target="RFC3326"/> protocol "STIR" protocol, "STIR", for STIR applications using SIP as defined in <xref target="RFC8224"/>.
The use of "STIR" as a reason Reason header field protocol with the error defined in <xref target="RFC8224"/> defined error cause causes codes allows to allow the use of multiple Reason header fields defined as detailed in <xref target="RFC3326"/> and updated in <xref target="I-D.ietf-sipcore-multiple-reasons"/>. target="RFC9366"/>. Any provisional SIP Response response message or final response message, with the exception of a 100 (Trying), MAY <bcp14>MAY</bcp14> contain one or more Reason header fields with a STIR related STIR-related cause code defined in <xref target="RFC8224"/> or future specifications. The use of multiple Reason header field fields is discussed in more detail later in the document.</t>
    </section>
    <section anchor="use-of-provisional-response-to-signal-errors-without-terminating-the-call"><name>Use anchor="use-of-provisional-response-to-signal-errors-without-terminating-the-call">
      <name>Use of provisional response Provisional Response to signal errors Signal Errors without terminating Terminating the call</name> Call</name>
      <t>In cases where local policy dictates that a call should continue regardless of any verification errors that may have occured, occurred, including 4XX 4xx errors described in <xref target="RFC8224"/> Section 6.2.2, then sectionFormat="of" target="RFC8224" section="6.2.2"/>, the verification service MUST NOT <bcp14>MUST NOT</bcp14> send the 4XX 4xx as a response, but rather response. Rather, it should include the error response code and reason phrase in a Reason header field, defined in <xref target="RFC3326"/>, field in the next provisional or final responses sent response it sends to the authentication service.</t>
      <t>Example Reason header field:</t>

<figure><artwork><![CDATA[
      <artwork><![CDATA[
Reason: STIR ;cause=436 ;text="Bad Identity Info"
]]></artwork></figure>
]]></artwork>
    </section>
    <section anchor="handling-of-a-verification-error-when-there-are-multiple-identity-header-fields"><name>Handling anchor="handling-of-a-verification-error-when-there-are-multiple-identity-header-fields">
      <name>Handling of a verification error when there are multiple Verification Error When There Are Multiple Identity header fields</name> Header Fields</name>
      <t>In cases where a SIP message includes multiple Identity header fields and one of those Identity header fields has an error, the verification service MUST <bcp14>MUST</bcp14> include the error response code and reason phrase associated with the error in a Reason header field, defined in <xref target="RFC3326"/>, in the next provisional or final responses sent to the authentication service. The reason cause in the Reason header field MUST <bcp14>MUST</bcp14> represent the error that occurred when verifying the contents of the Identity header field. For a SIP INVITE containing multiple Identity header fields, the "ppi" parameter for the Reason header field is RECOMMENDED. <bcp14>RECOMMENDED</bcp14>. As defined in <xref target="RFC8224"/>, the STIR error codes used in responses are based on an error associated with a specific identity Identity header field representing a single error occurring with the verification and processing of that identity Identity header field.
The association of a "ppi" parameter with a Reason header field <xref target="RFC3326"/> using "STIR" the protocol MUST value of "STIR" defined in this document <bcp14>MUST</bcp14> only identify a single cause code <xref target="RFC3326"/> in the context of a call dialog <xref target="RFC3261"/> corresponding only to the STIR-related error codes defined in <xref target="RFC8224"/> or in future documents defining STIR related errors. STIR-related error codes. The associated PASSporT object can be included either in full form or in compact form, where only the signature of the PASSporT is included with two periods as a prefix prefix, as defined in <xref target="RFC8225"/> Section 7 target="RFC8225" sectionFormat="of" section="7"/>, to identify the reported Identity header field with an error. Compact form is the recommended form form, as full form may include information that could have privacy or security implications in some call scenarios as scenarios; this is discussed in <xref target="Security"/>.</t>

      <t>Example Reason header field with a full form PASSporT:</t>

<figure><artwork><![CDATA[
      <artwork><![CDATA[
Reason: STIR ;cause=436 ;text="Bad Identity Info" ;ppi= \
"eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1I \
joiaHR0cHM6Ly9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJ \
kZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdC \
I6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.r \
q3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs \
ojNCpTzO3QfPOlckGaS6hEck7w"
]]></artwork></figure>
]]></artwork>
      <t>Example Reason header field with a compact form PASSporT:</t>

<figure><artwork><![CDATA[
      <artwork><![CDATA[
Reason: STIR ;cause=436 ;text="Bad Identity Info" ;ppi= \
"..rq3pjT1akEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs \
ojNCpTzO3QfPOlckGaS6hEck7w"
]]></artwork></figure>
]]></artwork>
    </section>
    <section anchor="handling-multiple-verification-errors"><name>Handling multiple verification errors</name> anchor="handling-multiple-verification-errors">
      <name>Handling Multiple Verification Errors</name>
      <t>If there are multiple Identity header field verification errors being reported reported, the verification service MUST <bcp14>MUST</bcp14> include a corresponding number of Reason header fields per error.  These Reason header fields should include a "ppi" parameters parameter, including the full or compact form of the PASSporT with cause and text parameters identifying each error. As mentioned previously, the potential use of multiple Reason header fields defined in <xref target="RFC3326"/> is updated in <xref target="I-D.ietf-sipcore-multiple-reasons"/> target="RFC9366"/>, allowing multiple Reason header fields with the same protocol value. For this specification, "STIR" should be used for any STIR error defined in <xref target="RFC8224"/> or future specifications.</t>
      <t>Example Reason header fields for two identity info errors:</t>

<figure><artwork><![CDATA[
      <artwork><![CDATA[
Reason: STIR ;cause=436 ;text="Bad Identity Info" ;ppi=     \
"..rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFY \
pFYsojNCpTzO3QfPOlckGaS6hEck7w"

Reason: STIR ;cause=438 ;text="Invalid Identity Header" ;ppi=  \
"..rJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYsq3pjT1hoRwakEGjHCnWSwUnsh \
d0-zckGaS6hEck7wojNCpTzO3QfPOl"

]]></artwork></figure>
]]></artwork>
    </section>
    <section anchor="removal-of-the-reason-header-field-by-authentication-service"><name>Removal anchor="removal-of-the-reason-header-field-by-authentication-service">
      <name>Removal of the Reason header field Header Field by Authentication Service</name>
      <t>When an Authentication Service authentication service <xref target="RFC8224"/> receives the Reason header field with a PASSporT it generated as part of an Identity header field and the authentication of a call, it should first follow local policy to recognize and acknowledge the error (e.g. (e.g., perform operational actions like logging or alarming), but then MUST alarming). Then, it <bcp14>MUST</bcp14> remove the identified Reason header field to avoid the PASSporT information from going upstream to a UAC User Agent Client (UAC) or UAS User Agent Server (UAS) that may not be authorized to see claim information contained in the PASSporT for privacy or other reasons.</t>
    </section>
    <section anchor="iana-considerations"><name>IANA anchor="iana-considerations">
      <name>IANA Considerations</name>

<t>This document requests
      <t>IANA has registered the definition of a following new protocol value (and associated protocol cause) to be registered by the IANA into in the "Reason Protocols" sub-registry registry under http://www.iana.org/assignments/sip-parameters as follows:</t>

<figure><artwork><![CDATA[
Protocol Value   Protocol Cause            Reference
--------------   ---------------           -----------
STIR             STIR Error code           RFC 8224

]]></artwork></figure>

<t>This document <eref target="http://www.iana.org/assignments/sip-parameters" brackets="angle"/>:</t>

<table anchor="iana1">
  <thead>
    <tr>
      <th>Protocol Value</th>
      <th>Protocol Cause</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>STIR</td>
      <td>STIR error code</td>
      <td><xref target="RFC8224"/></td>
    </tr>
  </tbody>
</table>

      <t>IANA has also requests the definition of registered a new header field parameter name to be registered by IANA into in the Header
"Header Field Parameters and Parameter Values sub-registry Values" registry under https://www.iana.org/assignments/sip-parameters as follows:</t>

<figure><artwork><![CDATA[
Header Field   Parameter Name   Predefined Values  Reference
------------   --------------   -----------------  ---------
Reason         ppi               No                RFC THIS

]]></artwork></figure> <eref target="https://www.iana.org/assignments/sip-parameters" brackets="angle"/>:</t>

<table anchor="iana2">
  <thead>
    <tr>
      <th>Header Field</th>
<th>Parameter Name</th>
<th>Predefined Values</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Reason</td>
      <td>ppi</td>
      <td>No</td>
      <td>RFC 9410</td>
    </tr>
  </tbody>
</table>

    </section>
    <section anchor="Security"><name>Security anchor="Security">
      <name>Security Considerations</name>
      <t>This specification discusses the use of a PASSporT as an identifier for cases where there are multiple identity header field errors occuring occurring as part of the Reason header field response. For some call scenarios (e.g. diversion based (e.g., diversion-based call flows) flows), the signer of the PASSporT(s) may not be the first hop first-hop initiator of the call. In those cases, there may be some security or privacy concerns associated with PASSporT information that is passed upstream beyond the authentication service that originally signed the PASSporT(s) in the resulting error Reason header field. This specification states that the authentication service MUST <bcp14>MUST</bcp14> remove the Reason header field with the PASSporT to protect the security (e.g. (e.g., use of a potentially still fresh still-fresh PASSporT for replay attacks) and privacy of any potential information that could be passed beyond the authentication service response back in the direction of the call initiator. While this specification allows for both the full and compact form of the PASSporT to be used as the error identifier, use of the compact form is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to avoid  the potential exposure of call information contained in the full form of the PASSporT.</t>
    </section>
  </middle>
  <back>

    <references title='Normative References'>

<reference anchor='I-D.ietf-sipcore-multiple-reasons' target='https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-multiple-reasons-01'>
   <front>
      <title>Multiple SIP Reason Header Field Values</title>
      <author fullname='Robert Sparks' initials='R.' surname='Sparks'>
         </author>
      <date day='23' month='August' year='2022'/>
      <abstract>
	 <t>   The SIP Reason Header Field as defined in RFC 3326 allows only one
   Reason value per protocol value.  Experience with more recently
   defined protocols shows it is useful to allow multiple values with
   the same protocol value.  This update to RFC 3326 allows multiple
   values for an indicated registered protocol when that protocol
   defines what the presence of multiple values means.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-sipcore-multiple-reasons-01'/>

</reference>

<reference anchor='RFC3261' target='https://www.rfc-editor.org/info/rfc3261'>
<front>
<title>SIP: Session Initiation Protocol</title>
<author fullname='J. Rosenberg' initials='J.' surname='Rosenberg'><organization/></author>
<author fullname='H. Schulzrinne' initials='H.' surname='Schulzrinne'><organization/></author>
<author fullname='G. Camarillo' initials='G.' surname='Camarillo'><organization/></author>
<author fullname='A. Johnston' initials='A.' surname='Johnston'><organization/></author>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/></author>
<author fullname='R. Sparks' initials='R.' surname='Sparks'><organization/></author>
<author fullname='M. Handley' initials='M.' surname='Handley'><organization/></author>
<author fullname='E. Schooler' initials='E.' surname='Schooler'><organization/></author>
<date month='June' year='2002'/>
<abstract><t>This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants.  These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3261'/>
<seriesInfo name='DOI' value='10.17487/RFC3261'/>
</reference>

<reference anchor='RFC3326' target='https://www.rfc-editor.org/info/rfc3326'>
<front>
<title>The Reason Header Field for the Session Initiation Protocol (SIP)</title>
<author fullname='H. Schulzrinne' initials='H.' surname='Schulzrinne'><organization/></author>
<author fullname='D. Oran' initials='D.' surname='Oran'><organization/></author>
<author fullname='G. Camarillo' initials='G.' surname='Camarillo'><organization/></author>
<date month='December' year='2002'/>
<abstract><t>The REGISTER function is used in a Session Initiation Protocol (SIP) system primarily to associate a temporary contact address with an address-of-record.  This contact is generally in the form of a Uniform Resource Identifier (URI), such as Contact: &lt;sip:alice@pc33.atlanta.com&gt; and is generally dynamic and associated with the IP address or hostname of the SIP User Agent (UA).  The problem is that network topology may have one or more SIP proxies between the UA and the registrar, such that any request traveling from the user's home network to the registered UA must traverse these proxies.  The REGISTER method does not give us a mechanism to discover and record this sequence of proxies in the registrar for future use.  This document defines an extension header field, &quot;Path&quot; which provides such a mechanism.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3326'/>
<seriesInfo name='DOI' value='10.17487/RFC3326'/>
</reference>

<reference anchor='RFC8224' target='https://www.rfc-editor.org/info/rfc8224'>
<front>
<title>Authenticated Identity Management in the Session Initiation Protocol (SIP)</title>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/></author>
<author fullname='C. Jennings' initials='C.' surname='Jennings'><organization/></author>
<author fullname='E. Rescorla' initials='E.' surname='Rescorla'><organization/></author>
<author fullname='C. Wendt' initials='C.' surname='Wendt'><organization/></author>
<date month='February' year='2018'/>
<abstract><t>The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context.  This document defines a mechanism for securely identifying originators of SIP requests.  It does so by defining a SIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer.</t><t>This document obsoletes RFC 4474.</t></abstract>
</front>
<seriesInfo name='RFC' value='8224'/>
<seriesInfo name='DOI' value='10.17487/RFC8224'/>
</reference>

<reference anchor='RFC8225' target='https://www.rfc-editor.org/info/rfc8225'>
<front>
<title>PASSporT: Personal Assertion Token</title>
<author fullname='C. Wendt' initials='C.' surname='Wendt'><organization/></author>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/></author>
<date month='February' year='2018'/>
<abstract><t>This document defines a method for creating and validating a token that cryptographically verifies an originating identity or, more generally, a URI or telephone number representing the originator of personal communications.  The Personal Assertion Token, PASSporT, is cryptographically signed to protect the integrity of the identity of the originator and to verify the assertion of the identity information at the destination.  The cryptographic signature is defined with the intention that it can confidently verify the originating persona even when the signature is sent to the destination party over an insecure channel.  PASSporT is particularly useful for many personal-communications applications over IP networks and other multi-hop interconnection scenarios where the originating and destination parties may not have a direct trusted relationship.</t></abstract>
</front>
<seriesInfo name='RFC' value='8225'/>
<seriesInfo name='DOI' value='10.17487/RFC8225'/>
</reference>

<reference anchor='RFC8226' target='https://www.rfc-editor.org/info/rfc8226'>
<front>
<title>Secure Telephone Identity Credentials: Certificates</title>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/></author>
<author fullname='S. Turner' initials='S.' surname='Turner'><organization/></author>
<date month='February' year='2018'/>
<abstract><t>In order to prevent the impersonation of telephone numbers on the Internet, some kind of credential system needs to exist that cryptographically asserts authority over telephone numbers.  This document describes the use of certificates in establishing authority over telephone numbers, as a component of a broader architecture for managing telephone numbers as identities in protocols like SIP.</t></abstract>
</front>
<seriesInfo name='RFC' value='8226'/>
<seriesInfo name='DOI' value='10.17487/RFC8226'/>
</reference>

<reference anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname='S. Bradner' initials='S.' surname='Bradner'><organization/></author>
<date month='March' year='1997'/>
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

<!-- [I-D.ietf-sipcore-multiple-reasons] Published as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>

<reference anchor='RFC8174' target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></author>
<date month='May' year='2017'/>
<abstract><t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference> 9366 -->

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9366.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3326.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8224.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8225.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8226.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7340.xml"/>
      </references>

    <references title='Informative References'>

<reference anchor='RFC7340' target='https://www.rfc-editor.org/info/rfc7340'>
<front>
<title>Secure Telephone Identity Problem Statement and Requirements</title>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/></author>
<author fullname='H. Schulzrinne' initials='H.' surname='Schulzrinne'><organization/></author>
<author fullname='H. Tschofenig' initials='H.' surname='Tschofenig'><organization/></author>
<date month='September' year='2014'/>
<abstract><t>Over the past decade, Voice over IP (VoIP) systems based on SIP have replaced many traditional telephony deployments.  Interworking VoIP systems with the traditional telephone network has reduced the overall level of calling party number and Caller ID assurances by granting attackers new and inexpensive tools to impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes, or even circumventing multi-factor authentication systems trusted by banks.  Despite previous attempts to provide a secure assurance of the origin of SIP communications, we still lack effective standards for identifying the calling party in a VoIP session.  This document examines the reasons why providing identity for telephone numbers on the Internet has proven so difficult and shows how changes in the last decade may provide us with new strategies for attaching a secure identity to SIP sessions.  It also gives high-level requirements for a solution in this space.</t></abstract>
</front>
<seriesInfo name='RFC' value='7340'/>
<seriesInfo name='DOI' value='10.17487/RFC7340'/>
</reference>
    </references>
    <section anchor="acknowledgements"><name>Acknowledgements</name> anchor="acknowledgements" numbered="false">
      <name>Acknowledgements</name>
      <t>The author would like to thank David Hancock <contact fullname="David Hancock"/> for help to identify identifying these error scenarios and additionally Jon Peterson, Roman Shpount, Robert Sparks, Christer Holmberg scenarios, as well as <contact fullname="Jon Peterson"/>, <contact fullname="Roman Shpount"/>, <contact fullname="Robert Sparks"/>, <contact fullname="Christer Holmberg"/>, and others in the STIR working group Working Group for their helpful feedback and discussion.</t>
    </section>
  </back>

<!-- ##markdown-source:
H4sIAGQZ+mMAA8VaW2/bOBZ+16/gpi8tYLvOpWmbwQCb5tI4SJxMnDRpdxcD
WqJtJrKoESU7bjD72/ecQ1KiHNmZYmawwQwqUyJ5rt+5kO12O8hlHos91otE
Ao8LdiJ4JDJ2lGUq0+yEJ1EskzEbqYwNrntXAR8OMzHzJpgvg0iFCZ/CSlHG
R3lbinzU1rnM2tJ+2J7Qym1B37cnduV290MQ8lyMVbbYYzqPgkCm2R7Ls0Ln
W93ux+5WwDPB99j+1XUwV9nDOFNFukfUsFv4jeR9xrHgQSzgg8i88371Lqsf
ju4g0DmQ8CuPVQJUL4QO9JRn+a+/FSoXeo8lirEglXvsX7kKW0yrLM/ESMPT
YooP/wkCXuQTle0FjLXhf8ZkAvMOOuxWJFFOI0YkB5NMam9UZWOgSk2VZr0k
7NCYmHIZ77EQPyXp/ZMe5zipk4g8CBKVTXkuZwI37LUPO0bGMg1VJtrTIs5l
Gos2yEorJOTFT2CZq+OD7a3dzT33YIfgcc89mKEPW1s7e+6hHHrnht6VQ7tu
CCYGMhn5RMOL99s73T33EATtdpvxoc4zHgKH1xMQExhSMQUdMfGYA/PaKBpU
xfKJYPsgclQgmkxUGeE5T/hY0DSZ0IcDobVUCQhY5hIogMfLTIEqVcxeg0W8
YWSIzNkhSzMViqjIhGa5glXCuIgELTXlaYpfqBGbiUyOcHNcbwQag++ZFSdO
I1ojMZIJULfz+MhCFcGCWtFC9Qm4Hk8qHox/sJEUccRCeDMUMD2ZiQWslZsV
ihRkJfiU8UoOSIoW2UyGgs1hkMUq5DFLVSzDBYtkmIOsgLoJz2kNeBkzPVEF
bqNgjaQQTmopsC8SWAhpa+S2w+pa4jEwZzjWNRnidiLhw1jASkucAzdDI1fD
Gmc6FSHutUIcCD86hOUyqezahYYVrEU3z9IoDthUqyluBi/5TBi1azIoBSzD
I75KVF7aWGkSIARwcNhHy7wgKWiGvBv9doz5TmUUxSIIXoGp5ZmKihA/RGMW
xhxGGYAAAhfjOFeHmRwC2yDxpyfrCL//juuCypfUWk1FAXANas6RMM5yEYt0
AtDFkmI6BI7h/c1Vjw25xrWdOAptPo/kWOZgFFqOE56jJpDZEJcjBQs78QVa
0dOBVpzrfu/Cb9A3qA+9PF50WPlqB165NbQxXy2MUJ+Jxnlt7xKNyLgprYOo
ZLd0VjYEvdHXK5yAzCMEU0Oz5+xyfzBIVXbdKh2zzk7LLh4D/WANkiBkpWM6
I6n5Rn1nlaFAVBKB7OOF/dJKwBFD6wjQXBQBQSoD/YBiUFlOd51lPIRncFfQ
GbIwlyADa8pA7ozHMjLz3Q7GxFc4Br6aqDmStGAQXmHl6bRILKzCguSPYDAh
mIWuSR98VcUFsQ2eOxFxyngUAceGwRSiJ+wIU6XWBan7JS91Ik0BIoAPeA+T
qnVqkjYsd9h+FEkcACxbtFBnlgYr5nJvArwCFAICRDw2oG/0o4XdGpRGwJkT
XKAnNmzaqsATvshFNkWNAQyA3xuIiUQaqwXqShNJiCtDYadpUSGwheaRH36s
LutwjbvpZ1gtZkCrHK0nl8ia8mRhVahGLdpQPPIp6AIITHgE01DKCB4qFRk3
EnW0EAmRImzMhAkNiJKLCl9GAP/VxvkiNZEjz8U0zVs+szBsGUBuS1ESLwCy
xdi4dLkysIX7WueJWr40gZQR0AiWahYnXuGFNoLWrXXoYKUJuSlsDwvCLrSD
sxZjIRSxnTMTtDFOwO4ic84fBHnASD4amaDJaRseXTgzW89xq0jqsNDPcPDK
RMQaxqD/FUMtfitQ4ICHM6mNZl5vPj6+Kc2XXB+yWpiYK4dgHhNDHj64zGGF
NFDzaEcGeTmACuSahMiwu0wJeOx2EkM5mVAtcQKcOlbZs8D5h52+9PMyyBrJ
k0tZIa1YA3HamBEaRwrxse4IwyL3Y7wX/tFCfGx14EbpngB7JHMATKHwmViz
hG0ry1gjVDQRAFNQX+x8ZbQAiJHhZEVUAVqGAvcqLZty0Ao7TK5oPBtzjWvC
HxWr8YI9vcqrX7+bzMPWO5ptnN8Mrjda5l/Wv6Dnq6NfbnpXR4f4PDjZPzsr
H9wXg5OLm7PD6qmaeXBxfn7UPzSTYZQtDZ3vf90wIXXj4vK6d9HfP9swrNTS
RkAukwXKBKgHj8bAs5x0fDq4ZJs7EKz/AdF6a3PzI2QC5seHzfeYXiBsm81U
Ei/sTxPUILfkGZlIjGEsxfwH9M4JT+focZDMoiibPLDMQTYwT9lYDsVVLEzE
vHEBk7tsU3q0tFhZSyONsbUdbVM1dEOumzIVYBfBpQQPuxhHKrJ1LFCqgIZU
z8vMBsaXQ46LmloFxKXmNZgqXbmB0eekWqZRJ0UauXzi6enFchT52wcg9fEO
xXHlgvUU4jtUeYhZsCW8zZbetCpexWMoUnJKqmQ2u132+jpbgIjftBiYKAUj
jvCZ0IJToKiZP1qSG4VlIiaGKnmt0BTRWFCiXQsFuqbCdYKlQsOEDLM6URgJ
IDpmSEXm8MFZJRnzjVnZl2EpJfA3yv/LAI+sKcBIl8z4kTkIeolNHUwVtaaq
5M01ZSbGPIPaSGsDX4umVM6sUMKzCiFbw3BvCnCkaOfursyOmioSFPdAmOC8
29nqbBECJKuzdIeEMGCDEG5hHcnIqkWxAxKiCcm56gUs5Y9kAmjq1gPTSYZo
TYGpQanPSxDjLS2ny0Q81gP+M1vXjLKwtVEdLOHIpHlNROwFwX+rv8B8Yftp
P5Fl/7yzvct+yoGWnzc+ca+I6CUjtVGbDSZ34kX9pkzUz60R9l/IDJ4ZHicU
cM5vlaH/UIJBzu2K+BXfTbguQ2vrBaP5cUuAnERBIZW7kq2a+f+2EQIiS6zB
M7t+ExgR91UNUHFB3ktOi0kLaZrEtyixBNAAK6K1qVyHYQppFN3rf+ldHzl8
xmVe0LRR2kaayg3IAbGjgOA4sjnpCmj1khaIOqsCbqtqVdhASSGysJBcyRvt
2nRQVFJa0zPle20u2ZgGlhI2XRvMCGInaSNkfFEaUs1Q0fao/6Z12bsC3TRu
ZJTvyCuj5LIMLdFNIjTZis1BylSDzIQysTLrLbnwYqZLbNE0wJZpb4ogEdQB
arwmpsKIDasu6lnVUe7kh2jXKPAZheGy/6KG9xAzXDVnHRumSQv5sA8QhO1r
u2+opimUgDTUstBErCIrVV/Nmnm5j9TV4kZxc8Wg1pYKMQpjDlazWEM2GuE7
L7i9p6LACTYn94U9ao3wmpKM/sqGwIHHAfUwaAXs/EAcFJEZBzIqzjEsO8wr
e/muQAsp2lPUTjM541jkQ3kkwEypgJ96ya20LRKTJ5SNXL6U4zw9Dex0SAbX
BjHDW0Wpk/efDW7sJ/CBn9m/gw2xOJ0MP4fyQp4e33zvbfZlT/eSq3fhQW+3
l3yahNv9+XD7tNuTcykOv2z2YNK9kvzkqhuenO+eLT7ef7s77Z5Nv+x8vd2c
Dz/fFPB5crZdTT2b9uNQnn7swF4w++HbXb/bu0/f95IvCz7o7d4uTr/zu/3d
r7eP6detL/vf7iaT4d0n/W3w7n641ZV3d13dm8aT6ABmA1X3R93+4fni/HD8
vX94I88OTmfhNE7MkldFD8g7v+499q9vNvvXRwt4lqO7bieD2b9tp/fXmxN1
NecPR5/vTw6S28H8JtGTqNv+frp7vPnlYnx8O7g/+ZR9+OU+vY8f2mF6/BX+
0zBb3fcP0uvvF9u/jC4v4vDhMx/sTo7Ch/fzpWzhRY36XvY3KLXTyQynfyuX
Xk5Uxq6G1BcyndEfzosac2fXM7Ao8MeSF17vUJcHCKPm+gewygEIgqleUSbZ
5L/aZCmYaC+jp7MwdF2KqJ7Cl8HTmAQFDuoXUebjrWixkPqnPJw4OiGeY2gA
CWCLMBMzqQqNfeJ6w+nPlLcAnz9a3ZrKumYUqwtOCirAZxVbZzwuhEmU8mct
xpYLxVYNQ2GSFDo2gsLLS2F+tGBd67Ta5Flz5TVuweOsff5Ffot/vu/+MErB
bHThdf67grgPjrheQkcsy/ckShINfeshZCX1MBsZ8Cmq07oRLAPMlZiqGeb+
q7vIw4V/Wo5wMDBwEAS3mKdDYtD8vmYXkCAIObOt0ZWwzb2EJ2djkeBhgmno
gb/ma4+6XSd4qU4ps0I6S7F2PZKZRqxAT6p3JCA1wlxmnMjvBix4+JCoeSyi
sV+vvRadcQcxzeCNd+hh2vuaxfIBmx3jMWXR4D4xx+4I9o2wJ0CtBVsOgQqE
d2pBpwhNIsIT7pmS0VJm6CVUo0xN2VjhluURP52L3+wf0NHu/qBqlOC5yNDI
S2XALm2gBWRXMZfT2rq2ijLuXtsd/dZL28whgMUq6iT19vv7kDImGpgzQtLL
bdAMTyh0bmzDpOGV6rAzWgcv9pr0UiXj5Wtytze2IZyJsdSA74JMmGpGJEUm
tp7dsCJ21zn0Bp6WtM20bMGKBCU/yfN07+3b+XzekTzhHZWN38LWkKdT1fAW
cLrthRJMe8mqlkALva28N/KFuGDVRZIDCk3e3xW27/ECBV4N8P7gVfvZiPvz
RgOCH/+PBo7K4tPf6/iA0W2cZXobLmi8qKl667isAPH+UqNa6iqxl8aOafal
J9XE+2nEp1cpS/9F2qrRwrzt+8gLKk+4EGgJWqG1Zzp7rkQcq3Rn7dL9QWBg
9b++WhogHV6f9AbPuHjFXCW05IPs6VVZI1lV1w8bXUFVa+F7+GzaXd6B1ogO
AKp+W0NG2tytsEkoNSaoYVGB/apg4TomJo9pKgkNQEd0F4PO8KirQh+NUOFv
ynrb5Kw+qL2Gtx5AUppJAWOiUibNRTBVzsI17cmxqp0cZ8IdNhOBZUXrIaa9
iKGftXga0d00YjSdUIqoQvihWKjm4Fe7UGJvh8TxwvAdPWPagjtIFzXmbhM0
aaDxfFq7Xv5KOpYD3spEoBZjAB0Q4rHPQkpzgjQ6tqZZ5uPIHh3Kj4CPST1S
QYkTg0p4nkNYB4ZNs8tGL3O24F08ae5UgD6tAl6We9nWpSN0d9AiM9uJ8Syo
sqsOu53IWDRk5+5MDTmhy0tU/NANrHXVj8FdyuO59jvHpe+2/JsE4VJ7x2tx
VhnIUgkkHlOlbdvKcrMmefBaYnVS7VU4FBZC136VehF8myNpk6+wOSmDsiyK
Hjx5YId8BrRB0Ryq0Nx1o3tFS+0uXV7OqBpImFB4V4HYKSYGFCSwKLpSU8C6
wSRVRZLjTyh0czYAlHoAV6druRgZTlSMJfDYvxToLqRh+J3bW8Z089h1lqUh
EmTCRkJEZCh0T8rgLxDUCf4HYXNgNGEtAAA=

-->
</rfc>