rfc9410xml2.original.xml   rfc9410.xml 
<?xml version="1.0" encoding="UTF-8"?> <?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 [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<rfc ipr="trust200902" docName="draft-ietf-stir-identity-header-errors-handling- <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
08" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="t -ietf-stir-identity-header-errors-handling-08" number="9410" submissionType="IET
rue"> F" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="tr
<front> ue" updates="" obsoletes="" xml:lang="en" version="3">
<title abbrev="Identity Errors">Identity Header Errors Handling for STIR</ti
tle>
<!-- xml2rfc v2v3 conversion 3.17.0 -->
<front>
<title abbrev="Identity Header Errors Handling for STIR">Handling of Identit
y Header Errors for Secure Telephone Identity Revisited (STIR)</title>
<seriesInfo name="RFC" value="9410"/>
<author initials="C." surname="Wendt" fullname="Chris Wendt"> <author initials="C." surname="Wendt" fullname="Chris Wendt">
<organization>Somos Inc.</organization> <organization>Somos Inc.</organization>
<address> <address>
<email>chris-ietf@chriswendt.net</email> <email>chris-ietf@chriswendt.net</email>
</address> </address>
</author> </author>
<date year="2023" month="July"/>
<date year="2023" month="February" day="25"/> <area>art</area>
<workgroup>stir</workgroup>
<area>ART</area>
<workgroup>STIR Working Group</workgroup>
<keyword>Identity</keyword> <keyword>Identity</keyword>
<keyword>multiple errors</keyword>
<keyword>passport</keyword>
<keyword>reason header field</keyword>
<abstract> <abstract>
<t>This document extends the current error-handling procedures for mapping
<t>This document extends STIR and the Authenticated Identity Management in the S of
ession Initiation Protocol (SIP) error handling procedures to include the mappin verification failure reasons to 4xx codes for Secure Telephone Identity Revisite
g of verification failure reasons to STIR defined 4xx codes so the failure reaso d (STIR)
n of an Identity header field can be conveyed to the upstream authentication ser and the Authenticated Identity Management in the Session Initiation
vice when local policy dictates that the call should continue in the presence of Protocol (SIP).
a verification failure. This document also defines procedures that enable a fai It extends the ability to use the Reason header field as an option for conveying
lure reason to be mapped to a specific Identity header field for scenarios that an error associated with an Identity header field to the upstream
use multiple Identity header fields where some may have errors and others may no authentication service when local policy dictates that the call
t and the handling of those situations is defined.</t> 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 hea
der fields, where some may have errors and others may not. The handling of those
situations is also defined.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction">
<name>Introduction</name>
<t>The STIR framework as described in <xref target="RFC7340"/> is an authe
ntication framework for asserting a telephone number or URI-based identity using
a digital signature and certificate-based framework, as described <xref target=
"RFC8225"/> and <xref target="RFC8226"/>, respectively.
<xref target="RFC8224"/> describes the use of the STIR framework in the SIP prot
ocol <xref target="RFC3261"/>. It defines both a) the authentication service tha
t creates a PASSporT <xref target="RFC8225"/> and delivers it in an Identity hea
der field, and b) the verification service that correspondingly verifies the PAS
SporT and embedded originating identity.</t>
<t>This document is concerned with errors in validating PASSporTs and Iden
tity header fields and how they are communicated in special cases. This document
also defines a solution to help address the potential issue of multiple Identit
y header fields and the plurality of potential verification errors.
Additionally, it addresses the issue of the current 4xx error response, i.e., th
e call is terminated when a verification error is present. In some deployments,
it may be the case that the policy for handling errors dictates that calls shoul
d continue even if there is a verification error.
For example, in many cases of inadvertent or operational errors that do not repr
esent any type of identity falsification attempt, the preferred policy may be to
continue the call despite the unverified identity. In these cases, the authenti
cation service should still be notified of the error so that corrective action c
an be taken to fix any issues. This specification will discuss the use of the Re
ason 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>To handle multiple Identity header fields where
some in a call may be verified while others may not (i.e., they have
errors), this document defines a method 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 key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</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 "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
<section anchor="reason-header-field-protocol-stir">
<name>Reason Header Field Protocol "STIR"</name>
<section anchor="introduction"><name>Introduction</name> <t>This document defines a new Reason header field <xref target="RFC3326"/
> protocol, "STIR", for STIR applications using SIP as defined in <xref target="
<t>The STIR framework as described in <xref target="RFC7340"/> is an authenticat RFC8224"/>.
ion framework for asserting a telephone number or URI based identity using a dig The use of "STIR" as a Reason header field protocol with the error defined in <x
ital signature and certificate based framework as described in <xref target="RFC ref target="RFC8224"/> causes codes to allow the use of multiple Reason header f
8225"/> and <xref target="RFC8226"/> respectively. <xref target="RFC8224"/> des ields as detailed in <xref target="RFC3326"/> and updated in <xref target="RFC93
cribes the use of the STIR framework in the SIP protocol <xref target="RFC3261"/ 66"/>. Any provisional SIP response message or final response message, with the
> and defines both the authentication service that creates a PASSporT, defined i exception of a 100 (Trying), <bcp14>MAY</bcp14> contain one or more Reason heade
n <xref target="RFC8225"/>, and delivers it in an Identity header field and the r fields with a STIR-related cause code defined in <xref target="RFC8224"/> or f
verification service that correspondingly verifies the PASSporT and embedded ori uture specifications. The use of multiple Reason header fields is discussed in m
ginating identity.</t> ore detail later in the document.</t>
</section>
<t>This document is concerned with errors in validating PASSporTs and Identity h <section anchor="use-of-provisional-response-to-signal-errors-without-termin
eader fields and how they are communicated in special cases and defines a soluti ating-the-call">
on to help address the potential issue of multiple Identity header fields and th <name>Use of Provisional Response to Signal Errors without Terminating the
e plurality of potential verification errors. Additionally, it addresses the iss Call</name>
ue of the current 4xx error response and that when there is a verification error <t>In cases where local policy dictates that a call should continue regard
, the call is terminated. In some deployments, it may be the case that the polic less of any verification errors that may have occurred, including 4xx errors des
y for handling errors dictates that calls should continue even if there is a ver cribed in <xref sectionFormat="of" target="RFC8224" section="6.2.2"/>, the verif
ification error. In many cases of, for example, inadvertent or operational error ication service <bcp14>MUST NOT</bcp14> send the 4xx as a response. Rather, it s
s that do not represent any identity falsification type of attempt, the policy o hould include the error response code and reason phrase in a Reason header field
f continuing the call even though the identity is not verified, may be the prefe in the next provisional or final response it sends to the authentication servic
rred policy. In these cases, the authentication service should still be notified e.</t>
of the error so that corrective action can be taken to fix any issues. This spe <t>Example Reason header field:</t>
cification will discuss the use of the Reason header field in subsequent provisi <artwork><![CDATA[
onal (1xx) responses in order to deliver the error back to the authentication se
rvice or other SIP path network equipment responsible for error handling.</t>
<t>For the handling of multiple Identity header fields and the potential situati
on that some of the Identity header fields in a call may pass verification but o
thers may have errors, this document defines the method of adding an identifier
so that the authentication service can uniquely identify which Identity header f
ield 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", and "OPTIONAL" in this do
cument are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xr
ef target="RFC8174"/> when, and only when, they appear in all capitals, as shown
here.</t>
</section>
<section anchor="reason-header-field-protocol-stir"><name>Reason header field pr
otocol "STIR"</name>
<t>This document defines a new Reason header field <xref target="RFC3326"/> prot
ocol "STIR" for STIR applications using SIP as defined in <xref target="RFC8224"
/>. The use of "STIR" as a reason header field protocol with the <xref target="R
FC8224"/> defined error cause codes allows the use of multiple Reason header fie
lds defined in <xref target="RFC3326"/> and updated in <xref target="I-D.ietf-si
pcore-multiple-reasons"/>. Any provisional SIP Response message or final respons
e message, with the exception of a 100 (Trying), MAY contain one or more Reason
header fields with a STIR related cause code defined in <xref target="RFC8224"/>
or future specifications. The use of multiple Reason header field is discussed
in more detail later in the document.</t>
</section>
<section anchor="use-of-provisional-response-to-signal-errors-without-terminatin
g-the-call"><name>Use of provisional response to signal errors without terminati
ng the call</name>
<t>In cases where local policy dictates that a call should continue regardless o
f any verification errors that may have occured, including 4XX errors described
in <xref target="RFC8224"/> Section 6.2.2, then the verification service MUST NO
T send the 4XX as a response, but rather include the error response code and rea
son phrase in a Reason header field, defined in <xref target="RFC3326"/>, in the
next provisional or final responses sent to the authentication service.</t>
<t>Example Reason header field:</t>
<figure><artwork><![CDATA[
Reason: STIR ;cause=436 ;text="Bad Identity Info" Reason: STIR ;cause=436 ;text="Bad Identity Info"
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="handling-of-a-verification-error-when-there-are-multiple-id
<section anchor="handling-of-a-verification-error-when-there-are-multiple-identi entity-header-fields">
ty-header-fields"><name>Handling of a verification error when there are multiple <name>Handling of a Verification Error When There Are Multiple Identity He
Identity header fields</name> ader Fields</name>
<t>In cases where a SIP message includes multiple Identity header fields a
<t>In cases where a SIP message includes multiple Identity header fields and one nd one of those Identity header fields has an error, the verification service <b
of those Identity header fields has an error, the verification service MUST inc cp14>MUST</bcp14> include the error response code and reason phrase associated w
lude the error response code and reason phrase associated with the error in a Re ith the error in a Reason header field, defined in <xref target="RFC3326"/>, in
ason header field, defined in <xref target="RFC3326"/>, in the next provisional the next provisional or final responses sent to the authentication service. The
or final responses sent to the authentication service. The reason cause in the R reason cause in the Reason header field <bcp14>MUST</bcp14> represent the error
eason header field MUST represent the error that occurred when verifying the con that occurred when verifying the contents of the Identity header field. For a SI
tents of the Identity header field. For a SIP INVITE containing multiple Identit P INVITE containing multiple Identity header fields, the "ppi" parameter for the
y header fields, the "ppi" parameter for the Reason header field is RECOMMENDED. Reason header field is <bcp14>RECOMMENDED</bcp14>. As defined in <xref target="
As defined in <xref target="RFC8224"/>, the STIR error codes used in responses RFC8224"/>, the STIR error codes used in responses are based on an error associa
are based on an error associated with a specific identity header field represent ted with a specific Identity header field representing a single error occurring
ing a single error occurring with the verification and processing of that identi with the verification and processing of that Identity header field.
ty header field. The association of a "ppi" parameter with a Reason header field The association of a "ppi" parameter with a Reason header field <xref target="RF
using "STIR" protocol MUST only identify a single cause code in the context of C3326"/> using the protocol value of "STIR" defined in this document <bcp14>MUST
a call dialog defined in <xref target="RFC8224"/> or in future documents definin </bcp14> only identify a single cause code <xref target="RFC3326"/> in the conte
g STIR related errors. The associated PASSporT object can be included either in xt of a call dialog <xref target="RFC3261"/> corresponding only to the STIR-rela
full form or in compact form, where only the signature of the PASSporT is includ ted error codes defined in <xref target="RFC8224"/> or future documents defining
ed with two periods as a prefix as defined in <xref target="RFC8225"/> Section 7 STIR-related error codes. The associated PASSporT object can be included either
to identify the reported Identity header field with an error. Compact form is t in full form or in compact form, where only the signature of the PASSporT is in
he recommended form as full form may include information that could have privacy cluded with two periods as a prefix, as defined in <xref target="RFC8225" sectio
or security implications in some call scenarios as discussed in <xref target="S nFormat="of" section="7"/>, to identify the reported Identity header field with
ecurity"/>.</t> an error. Compact form is the recommended form, as full form may include informa
tion that could have privacy or security implications in some call scenarios; th
<t>Example Reason header field with full form PASSporT:</t> is is discussed in <xref target="Security"/>.</t>
<figure><artwork><![CDATA[ <t>Example Reason header field with a full form PASSporT:</t>
<artwork><![CDATA[
Reason: STIR ;cause=436 ;text="Bad Identity Info" ;ppi= \ Reason: STIR ;cause=436 ;text="Bad Identity Info" ;ppi= \
"eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1I \ "eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1I \
joiaHR0cHM6Ly9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJ \ joiaHR0cHM6Ly9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJ \
kZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdC \ kZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdC \
I6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.r \ I6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.r \
q3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs \ q3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs \
ojNCpTzO3QfPOlckGaS6hEck7w" ojNCpTzO3QfPOlckGaS6hEck7w"
]]></artwork></figure> ]]></artwork>
<t>Example Reason header field with a compact form PASSporT:</t>
<t>Example Reason header field with compact form PASSporT:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
Reason: STIR ;cause=436 ;text="Bad Identity Info" ;ppi= \ Reason: STIR ;cause=436 ;text="Bad Identity Info" ;ppi= \
"..rq3pjT1akEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs \ "..rq3pjT1akEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs \
ojNCpTzO3QfPOlckGaS6hEck7w" ojNCpTzO3QfPOlckGaS6hEck7w"
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="handling-multiple-verification-errors">
<section anchor="handling-multiple-verification-errors"><name>Handling multiple <name>Handling Multiple Verification Errors</name>
verification errors</name> <t>If there are multiple Identity header field verification errors being r
eported, the verification service <bcp14>MUST</bcp14> include a corresponding nu
<t>If there are multiple Identity header field verification errors being reporte mber of Reason header fields per error. These Reason header fields should inclu
d the verification service MUST include a corresponding number of Reason header de a "ppi" parameter, including the full or compact form of the PASSporT with ca
fields per error. These Reason header fields should include a "ppi" parameters use and text parameters identifying each error. As mentioned previously, the pot
including the full or compact form of the PASSporT with cause and text parameter ential use of multiple Reason header fields defined in <xref target="RFC3326"/>
s identifying each error. As mentioned previously, the potential use of multiple is updated in <xref target="RFC9366"/>, allowing multiple Reason header fields w
Reason header fields defined in <xref target="RFC3326"/> is updated in <xref ta ith the same protocol value. For this specification, "STIR" should be used for a
rget="I-D.ietf-sipcore-multiple-reasons"/> allowing multiple Reason header field ny STIR error defined in <xref target="RFC8224"/> or future specifications.</t>
s with the same protocol value. For this specification, "STIR" should be used fo <t>Example Reason header fields for two identity info errors:</t>
r any STIR error defined in <xref target="RFC8224"/> or future specifications.</ <artwork><![CDATA[
t>
<t>Example Reason header fields for two identity info errors:</t>
<figure><artwork><![CDATA[
Reason: STIR ;cause=436 ;text="Bad Identity Info" ;ppi= \ Reason: STIR ;cause=436 ;text="Bad Identity Info" ;ppi= \
"..rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFY \ "..rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFY \
pFYsojNCpTzO3QfPOlckGaS6hEck7w" pFYsojNCpTzO3QfPOlckGaS6hEck7w"
Reason: STIR ;cause=438 ;text="Invalid Identity Header" ;ppi= \ Reason: STIR ;cause=438 ;text="Invalid Identity Header" ;ppi= \
"..rJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYsq3pjT1hoRwakEGjHCnWSwUnsh \ "..rJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYsq3pjT1hoRwakEGjHCnWSwUnsh \
d0-zckGaS6hEck7wojNCpTzO3QfPOl" d0-zckGaS6hEck7wojNCpTzO3QfPOl"
]]></artwork>
</section>
<section anchor="removal-of-the-reason-header-field-by-authentication-servic
e">
<name>Removal of the Reason Header Field by Authentication Service</name>
<t>When an authentication service <xref target="RFC8224"/> receives the Re
ason header field with a PASSporT it generated as part of an Identity header fie
ld and the authentication of a call, it should first follow local policy to reco
gnize and acknowledge the error (e.g., perform operational actions like logging
or alarming). Then, it <bcp14>MUST</bcp14> remove the identified Reason header f
ield to avoid the PASSporT information from going upstream to a User Agent Clien
t (UAC) or User Agent Server (UAS) that may not be authorized to see claim infor
mation contained in the PASSporT for privacy or other reasons.</t>
</section>
<section anchor="iana-considerations">
<name>IANA Considerations</name>
<t>IANA has registered the following new protocol value (and associated pr
otocol cause) in the "Reason Protocols" registry under <eref target="http://www.
iana.org/assignments/sip-parameters" brackets="angle"/>:</t>
]]></artwork></figure> <table anchor="iana1">
<thead>
</section> <tr>
<section anchor="removal-of-the-reason-header-field-by-authentication-service">< <th>Protocol Value</th>
name>Removal of the Reason header field by Authentication Service</name> <th>Protocol Cause</th>
<th>Reference</th>
<t>When an Authentication Service <xref target="RFC8224"/> receives the Reason h </tr>
eader field with a PASSporT it generated as part of an Identity header field and </thead>
the authentication of a call, it should first follow local policy to recognize <tbody>
and acknowledge the error (e.g. perform operational actions like logging or alar <tr>
ming), but then MUST remove the identified Reason header field to avoid the PASS <td>STIR</td>
porT information from going upstream to a UAC or UAS that may not be authorized <td>STIR error code</td>
to see claim information contained in the PASSporT for privacy or other reasons. <td><xref target="RFC8224"/></td>
</t> </tr>
</tbody>
</section> </table>
<section anchor="iana-considerations"><name>IANA Considerations</name>
<t>This document requests the definition of a new protocol value (and associated
protocol cause) to be registered by the IANA into the "Reason Protocols" sub-re
gistry 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 also requests the definition of a new header field parameter na
me to be registered by IANA into the Header Field Parameters and Parameter Value
s sub-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>
</section>
<section anchor="Security"><name>Security Considerations</name>
<t>This specification discusses the use of a PASSporT as an identifier for cases <t>IANA has also registered a new header field parameter name in the
where there are multiple identity header field errors occuring as part of the R "Header Field Parameters and Parameter Values" registry under <eref target="http
eason header field response. For some call scenarios (e.g. diversion based call s://www.iana.org/assignments/sip-parameters" brackets="angle"/>:</t>
flows) the signer of the PASSporT(s) may not be the first hop initiator of the c
all. In those cases, there may be some security or privacy concerns associated w
ith PASSporT information that is passed upstream beyond the authentication servi
ce that originally signed the PASSporT(s) in the resulting error Reason header f
ield. This specification states the authentication service MUST remove the Reaso
n header field with the PASSporT to protect the security (e.g. use of potentiall
y still fresh PASSporT for replay attacks) and privacy of any potential informat
ion that could be passed beyond the authentication service response back in the
direction of the call initiator. While this specification allows for both full a
nd compact form of the PASSporT to be used as the error identifier, use of the c
ompact form is RECOMMENDED to avoid the potential exposure of call information
contained in the full form of the PASSporT.</t>
</section> <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 Considerations</name>
<t>This specification discusses the use of a PASSporT as an identifier for
cases where there are multiple identity header field errors occurring as part o
f the Reason header field response. For some call scenarios (e.g., diversion-bas
ed call flows), the signer of the PASSporT(s) may not be the first-hop initiator
of the call. In those cases, there may be some security or privacy concerns ass
ociated with PASSporT information that is passed upstream beyond the authenticat
ion service that originally signed the PASSporT(s) in the resulting error Reason
header field. This specification states that the authentication service <bcp14>
MUST</bcp14> remove the Reason header field with the PASSporT to protect the sec
urity (e.g., use of a potentially still-fresh PASSporT for replay attacks) and p
rivacy of any potential information that could be passed beyond the authenticati
on service response back in the direction of the call initiator. While this spec
ification allows for both the full and compact form of the PASSporT to be used a
s the error identifier, use of the compact form is <bcp14>RECOMMENDED</bcp14> to
avoid the potential exposure of call information contained in the full form of
the PASSporT.</t>
</section>
</middle> </middle>
<back> <back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<references title='Normative References'> <!-- [I-D.ietf-sipcore-multiple-reasons] Published as RFC 9366 -->
<reference anchor='I-D.ietf-sipcore-multiple-reasons' target='https://datatracke
r.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'><organizat
ion/></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/></aut
hor>
<author fullname='M. Handley' initials='M.' surname='Handley'><organization/></a
uthor>
<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 appli
cation-layer control (signaling) protocol for creating, modifying, and terminati
ng sessions with one or more participants. These sessions include Internet tele
phone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TR
ACK]</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'><organizat
ion/></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-r
ecord. 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 dynam
ic and associated with the IP address or hostname of the SIP User Agent (UA). T
he 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 netw
ork 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 r
egistrar 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/></autho
r>
<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 use
rs that originate SIP requests, especially in an interdomain context. This docu
ment 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 val
idating the identity and for conveying a reference to the credentials of the sig
ner.</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/></autho
r>
<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 UR
I or telephone number representing the originator of personal communications. T
he Personal Assertion Token, PASSporT, is cryptographically signed to protect th
e integrity of the identity of the originator and to verify the assertion of the
identity information at the destination. The cryptographic signature is define
d 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 ov
er IP networks and other multi-hop interconnection scenarios where the originati
ng and destination parties may not have a direct trusted relationship.</t></abst
ract>
</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/></aut
hor>
<date month='February' year='2018'/>
<abstract><t>In order to prevent the impersonation of telephone numbers on the I
nternet, some kind of credential system needs to exist that cryptographically as
serts authority over telephone numbers. This document describes the use of cert
ificates in establishing authority over telephone numbers, as a component of a b
roader architecture for managing telephone numbers as identities in protocols li
ke 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/></a
uthor>
<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 as they should be interpreted in IETF documents.
This document specifies an Internet Best Current Practices for the Internet Comm
unity, 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/></autho
r>
<date month='May' year='2017'/>
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s
pecifications. This document aims to reduce the ambiguity by clarifying that on
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs
tract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>
</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'><organizat
ion/></author>
<author fullname='H. Tschofenig' initials='H.' surname='Tschofenig'><organizatio
n/></author>
<date month='September' year='2014'/>
<abstract><t>Over the past decade, Voice over IP (VoIP) systems based on SIP hav
e replaced many traditional telephony deployments. Interworking VoIP systems wi
th the traditional telephone network has reduced the overall level of calling pa
rty number and Caller ID assurances by granting attackers new and inexpensive to
ols to impersonate or obscure calling party numbers when orchestrating bulk comm
ercial calling schemes, hacking voicemail boxes, or even circumventing multi-fac
tor authentication systems trusted by banks. Despite previous attempts to provi
de a secure assurance of the origin of SIP communications, we still lack effecti
ve standards for identifying the calling party in a VoIP session. This document
examines the reasons why providing identity for telephone numbers on the Intern
et 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>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
366.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
261.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
326.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
224.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
225.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
226.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
340.xml"/>
</references>
</references> </references>
<section anchor="acknowledgements" numbered="false">
<section anchor="acknowledgements"><name>Acknowledgements</name> <name>Acknowledgements</name>
<t>The author would like to thank <contact fullname="David Hancock"/> for
<t>The author would like to thank David Hancock for help to identify these error help identifying these error scenarios, as well as <contact fullname="Jon Peters
scenarios and additionally Jon Peterson, Roman Shpount, Robert Sparks, Christer on"/>, <contact fullname="Roman Shpount"/>, <contact fullname="Robert Sparks"/>,
Holmberg and others in the STIR working group for their helpful feedback and di <contact fullname="Christer Holmberg"/>, and others in the STIR Working Group f
scussion.</t> or their helpful feedback and discussion.</t>
</section>
</section>
</back> </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> </rfc>
 End of changes. 27 change blocks. 
533 lines changed or deleted 265 lines changed or added

This html diff was produced by rfcdiff 1.48.