rfc9027xml2.original.xml   rfc9027.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.15 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc ipr="trust200902" docName="draft-ietf-stir-rph-emergency-services-07" categ <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
ory="std"> -ietf-stir-rph-emergency-services-07" number="9027" obsoletes="" updates=""
submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="
true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.5.0 -->
<front> <front>
<title abbrev="RPH Values for Emergency Services">Assertion Values for a Res <title abbrev="RPH Values for Emergency Services">Assertion Values for Resou
ource Priority Header Claim and a SIP Priority Header Claim in Support of Emerge rce Priority Header and SIP Priority Header Claims in Support of Emergency Servi
ncy Services Networks</title> ces Networks</title>
<seriesInfo name="RFC" value="9027"/>
<author initials="M." surname="Dolly" fullname="Martin Dolly"> <author initials="M." surname="Dolly" fullname="Martin Dolly">
<organization>AT&amp;T</organization> <organization>AT&amp;T</organization>
<address> <address>
<email>md3135@att.com</email> <email>md3135@att.com</email>
</address> </address>
</author> </author>
<author initials="C." surname="Wendt" fullname="Chris Wendt"> <author initials="C." surname="Wendt" fullname="Chris Wendt">
<organization>Comcast</organization> <organization>Comcast</organization>
<address> <address>
<postal> <postal>
<street>Comcast Technology Center</street> <street>Comcast Technology Center</street>
<city>Philadelphia, PA 19103</city> <city>Philadelphia</city>
<country>USA</country> <region>PA</region>
<code>19103</code>
<country>United States of America</country>
</postal> </postal>
<email>chris-ietf@chriswendt.net</email> <email>chris-ietf@chriswendt.net</email>
</address> </address>
</author> </author>
<date year="2021" month="June"/>
<date year="2021" month="March" day="11"/>
<area>ART</area> <area>ART</area>
<workgroup>STIR</workgroup> <workgroup>STIR</workgroup>
<keyword>Internet-Draft</keyword> <keyword>rph</keyword>
<keyword>PASSporT</keyword>
<abstract> <keyword>esnet</keyword>
<t>This document adds new assertion values for a Resource Priority Header (“rph”
) claim and a new SIP Priority Header claim (“sph”) for protection of the “psap-
callback” value as part of the “rph” PASSporT extension, in support of the secur
ity of Emergency Services Networks for emergency call origination and callback.<
/t>
<abstract>
<t>This document adds new assertion values for a Resource Priority Header
("rph") claim and a new SIP Priority Header ("sph") claim for protection of the
"psap-callback" value as part of the "rph" Personal Assertion Token (PASSporT) e
xtension in support of the security of emergency services networks for emergency
call origination and callback.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name>
<t>"Personal Assertion Token (PASSporT) Extension for Resource Priority Au
thorization" <xref target="RFC8443" format="default"/> extended the Personal Ass
ertion Token (PASSporT) specification defined in <xref target="RFC8225" format="
default"/> to allow the inclusion of cryptographically signed assertions of auth
orization for the values populated in the Session Initiation Protocol (SIP) 'Res
ource-Priority' header field <xref target="RFC4412" format="default"/>. <xref ta
rget="I-D.rosen-stir-emergency-calls" format="default"/> introduces the need and
justification for the protection of both the SIP 'Resource-Priority' and 'Prior
ity' header fields, used for categorizing the priority use of the call in the te
lephone network, specifically for emergency calls.</t>
<t>Compromise of the SIP 'Resource-Priority' or 'Priority' header fields c
ould lead to misuse of network resources (i.e., during congestion scenarios), im
pacting the application services supported using the SIP 'Resource-Priority' hea
der field and the handling of Public Safety Answering Point (PSAP) callbacks.</t
>
<section anchor="introduction" title="Introduction"> <t><xref target="RFC8225" format="default"/> allows extensions by which an
authority on the originating side verifying the authorization of a particular c
<t>Personal Assertion Token (PASSporT) Extension for Resource Priority Authoriza ommunication for the SIP 'Resource-Priority' header field or the SIP 'Priority'
tion <xref target="RFC8443"/> extended the Personal Assertion Token (PASSporT) s header field can use PASSporT claims to cryptographically sign the information a
pecification defined in <xref target="RFC8225"/> to allow the inclusion of crypt ssociated with either the SIP 'Resource-Priority' or the 'Priority' header field
ographically signed assertions of authorization for the values populated in the and convey assertion of those values by the signing party authorization. A sig
Session Initiation Protocol (SIP) “Resource-Priority” header field <xref target= ned SIP 'Resource-Priority' or 'Priority' header field will allow a receiving en
"RFC4412"/>. <xref target="I-D.rosen-stir-emergency-calls"/> introduces the need tity (including entities located in different network domains/boundaries) to ver
and justification for the protection of both the SIP “Resource-Priority” and “P ify the validity of assertions to act on the information with confidence that it
riority” header fields, used for categorizing the priority use of the call in th has not been spoofed or compromised.</t>
e telephone network, specifically for emergency calls.</t>
<t>Compromise of the SIP “Resource-Priority” or “Priority” header fields could l
ead to misuse of network resources (i.e., during congestion scenarios), impactin
g the application services supported using the SIP “Resource-Priority” header fi
eld and the handling of Public Saftey Answering Point (PSAP) callbacks.</t>
<t><xref target="RFC8225"/> allows extensions by which an authority on the origi
nating side verifying the authorization of a particular communication for the SI
P “Resource-Priority” header field or the SIP “Priority” header field can use PA
SSPorT claims to cryptographically sign the information associated with either t
he SIP “Resource-Priority” or “Priority” header field and convey assertion of th
ose values by the signing party authorization. A signed SIP “Resource-Priority”
or “Priority” header field will allow a receiving entity (including entities lo
cated in different network domains/boundaries) to verify the validity of asserti
ons to act on the information with confidence that the information has not been
spoofed or compromised.</t>
<t>This document adds new “auth” array key values for a Resource Priority Header
(“rph”) claim defined in <xref target="RFC8443"/>, in support of Emergency Serv
ices Networks for emergency call origination and callback. This document additio
nally defines a new PASSporT claim, “sph”, including protection of the SIP Prior
ity header field for the indication of an emergency service call-back assigned t
he value “psap-callback” as defined in <xref target="RFC7090"/>.
The use of the newly defined claim and key values corresponding to the SIP ‘Reso
urce-Priority’ and ‘Priority’ header fields for emergency services is introduced
in <xref target="I-D.rosen-stir-emergency-calls"/> but otherwise out-of-scope o
f this document. In addition, the PASSPorT claims and values defined in this do
cument are intended for use in environments where there are means to verify that
the signer of the SIP ‘Resource-Priority’ and ‘Priority’ header fields is autho
ritative.</t>
</section>
<section anchor="terminology" title="Terminology">
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”,
“SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this d
ocument are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <x
ref target="RFC8174"/> when, and only when, they appear in all capitals, as show
n here.</t>
</section>
<section anchor="new-assertion-values-for-rph-claim" title="New Assertion Values
for “rph” claim">
<t>This specification defines the ability to sign the SIP Resource-Priority Head
er field namespace for local emergency communications defined in <xref target="R
FC7135"/> and represented by the string “esnet.x” where x is the priority-level
allowed in the esnet namespace. As of the writing of this specification the prio
rity-level is between 0 and 4, inclusive, but may be extended by future specific
ations.</t>
<t>Similar to the values defined by <xref target="RFC8443"/> for the “auth” JSON
object key inside the “rph” claim, the string “esnet.x” with the appropriate va
lue should be used when resource priority is required for local emergency commun
ications corresponding and exactly matching the SIP Resource-Priority header fie
ld representing the namespace invoked in the call.</t>
<t>When using “esnet.x” as the “auth” assertion value in emergency service desti
ned calls, the “orig” claim of the PASSporT MUST represent the calling party num
ber that initiates the call to emergency services. The “dest” claim MUST either
be a country or region specific dial string (e.g., “911” for North America or “
112” GSM defined string used in Europe and other countries) or “urn:service:sos”
as defined in <xref target="RFC5031"/>, representing the emergency services des
tination of the call.</t>
<t>The following is an example of an “rph” claim for SIP ‘Resource-Priority’ hea <t>This document adds new "auth" array key values for a Resource Priority
der field with an “esnet.1” assertion:</t> Header ("rph") claim defined in <xref target="RFC8443" format="default"/>, in su
pport of emergency services networks for emergency call origination and callback
. This document additionally defines a new PASSporT claim, "sph", including prot
ection of the SIP 'Priority' header field for the indication of an emergency ser
vice callback assigned the value "psap-callback", as defined in <xref target="RF
C7090" format="default"/>.
The use of the newly defined claim and key values corresponding to the SIP 'Reso
urce-Priority' and 'Priority' header fields for emergency services is introduced
in <xref target="I-D.rosen-stir-emergency-calls" format="default"/> but otherwi
se is out of scope of this document. In addition, the PASSporT claims and value
s defined in this document are intended for use in environments where there are
means to verify that the signer of the SIP 'Resource-Priority' and 'Priority' he
ader fields is authoritative.</t>
</section>
<section anchor="terminology" numbered="true" toc="default">
<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="new-assertion-values-for-rph-claim" numbered="true" toc="de
fault">
<name>New Assertion Values for "rph" Claim</name>
<t>This specification defines the ability to sign the SIP 'Resource-Priori
ty' header field namespace for local emergency communications defined in <xref t
arget="RFC7135" format="default"/> and represented by the string "esnet.x", wher
e x is the priority level allowed in the esnet namespace. As of the writing of t
his specification, the priority level is between 0 and 4, inclusive, but may be
extended by future specifications.</t>
<t>Similar to the values defined by <xref target="RFC8443" format="default
"/> for the "auth" JSON object key inside the "rph" claim, the string "esnet.x"
with the appropriate value should be used when resource priority is required for
local emergency communications corresponding and exactly matching the SIP 'Reso
urce-Priority' header field representing the namespace invoked in the call.</t>
<t>When using "esnet.x" as the "auth" assertion value in emergency-service
-destined calls, the "orig" claim of the PASSporT <bcp14>MUST</bcp14> represent
the calling party number that initiates the call to emergency services. The "de
st" claim <bcp14>MUST</bcp14> be either a country- or region-specific dial strin
g (e.g., "911" for North America or a "112" GSM-defined string used in Europe an
d other countries) or "urn:service:sos", as defined in <xref target="RFC5031" fo
rmat="default"/>, representing the emergency services destination of the call.</
t>
<t>The following is an example of an "rph" claim for the SIP 'Resource-Pri
ority' header field with an "esnet.1" assertion:</t>
<figure><artwork><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"dest":{"uri":["urn:service:sos"]}, "dest":{"uri":["urn:service:sos"]},
"iat":1615471428, "iat":1615471428,
"orig":{"tn":“12155551212"}, "orig":{"tn":"12155551212"},
"rph":{"auth":["esnet.1"]} "rph":{"auth":["esnet.1"]}
} }
]]></artwork></figure> ]]></sourcecode>
<t>For emergency services callbacks, the "orig" claim of the "rph" PASSpor
<t>For emergency services callbacks, the “orig” claim of the “rph” PASSporT MUST T <bcp14>MUST</bcp14> represent the Public Safety Answering Point (PSAP) telepho
represent the Public Saftey Answering Point (PSAP) telephone number. The “dest” ne number. The "dest" claim <bcp14>MUST</bcp14> be the telephone number represen
claim MUST be the telephone number representing the original calling party of t ting the original calling party of the emergency service call that is being call
he emergency service call that is being called back.</t> ed back.</t>
<t>The following is an example of an "rph" claim for the SIP 'Resource-Pri
<t>The following is an example of an “rph” claim for SIP ‘Resource-Priority’ hea ority' header field with an "esnet.0" assertion:</t>
der field with a “esnet.0” assertion:</t> <sourcecode type="json"><![CDATA[
<figure><artwork><![CDATA[
{ {
"dest":{"tn":["12155551212"]}, "dest":{"tn":["12155551212"]},
"iat":1615471428, "iat":1615471428,
"orig":{"tn":"12155551213"}, "orig":{"tn":"12155551213"},
"rph":{"auth":["esnet.0"]} "rph":{"auth":["esnet.0"]}
} }
]]></artwork></figure> ]]></sourcecode>
<t>After the header and claims PASSporT objects have been constructed, the
<t>After the header and claims PASSporT objects have been constructed, their sig ir signature is generated normally per the guidance in <xref target="RFC8225" fo
nature is generated normally per the guidance in <xref target="RFC8225"/> using rmat="default"/>, using the full form of PASSporT. The credentials (i.e., Certi
the full form of PASSPorT. The credentials (i.e., Certificate) used to create t ficate) used to create the signature must have authority over the namespace of t
he signature must have authority over the namespace of the “rph” claim, and ther he "rph" claim, and there is only one authority per claim. The authority <bcp14>
e is only one authority per claim. The authority MUST use its credentials associ MUST</bcp14> use its credentials associated with the specific service supported
ated with the specific service supported by the resource priority namespace in t by the resource priority namespace in the claim. If r-values are added or droppe
he claim. If r-values are added or dropped by the intermediaries along the path, d by the intermediaries along the path, the intermediaries must generate a new "
the intermediaries must generate a new “rph” identity header and sign the claim rph" identity header and sign the claim with their own authority.</t>
with their own authority.</t> </section>
<section anchor="the-sip-priority-header-sph-claim" numbered="true" toc="def
</section> ault">
<section anchor="the-sip-priority-header-sph-claim" title="The SIP Priority head <name>The SIP Priority Header ("sph") Claim</name>
er “sph” claim"> <t>As defined in <xref target="RFC7090" format="default"/>, the SIP 'Prior
ity' header field may be set to the value "psap-callback" for emergency services
<t>As defined in <xref target="RFC7090"/> the SIP Priority header field may be s callback calls. Because some SIP networks may act on this value and provide pr
et to the value “psap-callback” for emergency services callback calls. Because iority or other special routing based on this value, it is important to protect
some SIP networks may act on this value and provide priority or other special ro and validate the authoritative use associated with it.</t>
uting based on this value, it is important to protect and validate the authorita <t>Therefore, we define a new claim key as part of the "rph" PASSporT, "sp
tive use associated with it.</t> h". This is an optional claim that <bcp14>MUST</bcp14> only be used with an "au
th" claim with an "esnet.x" value indicating an authorized emergency callback ca
<t>Therefore, we define a new claim key as part of the “rph” PASSporT, “sph”. T ll and corresponding to a SIP 'Priority' header field with the value "psap-callb
his is an optional claim that MUST only be used only with an “auth” claim with a ack".</t>
n “esnet.x” value indicating an authorized emergency callback call and correspon <t>The value of the "sph" claim key should only be "psap-callback", which
ding to a SIP Priority header field with the value “psap-callback”.</t> <bcp14>MUST</bcp14> match the SIP 'Priority' header field value for authorized e
mergency services callbacks. If the value is anything other than "psap-callback"
<t>The value of the “sph” claim key should only be “psap-callback” which MUST ma , the PASSporT validation <bcp14>MUST</bcp14> be considered a failure case.</t>
tch the SIP Priority header field value for authorized emergency services callba <t>Note that because the intended use of this specification is only for em
cks. If the value is anything other than “psap-callback”, the PASSporT validatio ergency services, there is also an explicit assumption that the signer of the "r
n MUST be considered a failure case.</t> ph" PASSporT can authoritatively represent both the content of the 'Resource-Pri
ority' header field and 'Priority' header field information associated specifica
<t>Note: Because the intended use of this specification is only for emergency se lly with an emergency services callback case where both could exist. This docume
rvices, there is also an explicit assumption that the signer of the “rph” PASSpo nt is not intended to be a general mechanism for protecting the SIP 'Priority' h
rT can authoritatively represent both the content of the Resource Priority Heade eader fields; this could be accomplished as part of future work with a new PASSp
r field and Priority Header field information associated specifically with a eme orT extension or new claim added to either an existing PASSporT or PASSporT exte
rgency services callback case where both could exist. This document is not inten nsion usage.</t>
ded to be a general mechanism for protecting SIP Priority Header fields, this co <t>The following is an example of an "sph" claim for the SIP 'Priority' he
uld be accomplished as part of future work with a new PASSporT extension or new ader field with the value "psap-callback":</t>
claim added to either an existing PASSporT or PASSporT extension usage.</t> <sourcecode type="json"><![CDATA[
<t>The following is an example of an “sph” claim for SIP ‘Priority’ header field
with the value “psap-callback”:</t>
<figure><artwork><![CDATA[
{ {
"dest":{"tn":["12155551212"]}, "dest":{"tn":["12155551212"]},
"iat":1615471428, "iat":1615471428,
"orig":{"tn":"12155551213"}, "orig":{"tn":"12155551213"},
"rph":{"auth":["esnet.0"]}, "rph":{"auth":["esnet.0"]},
"sph":"psap-callback" "sph":"psap-callback"
} }
]]></artwork></figure> ]]></sourcecode>
</section>
</section> <section anchor="order-of-claim-keys" numbered="true" toc="default">
<section anchor="order-of-claim-keys" title="Order of Claim Keys"> <name>Order of Claim Keys</name>
<t>The order of the claim keys <bcp14>MUST</bcp14> follow the rules of <xr
<t>The order of the claim keys MUST follow the rules of <xref target="RFC8225"/> ef target="RFC8225" sectionFormat="of" section="9"/>, which defines the determin
Section 9 which defines the deterministic JSON serialization used for signature istic JSON serialization used for signature generation (and validation); the cla
generation (and validation); the claim keys MUST appear in lexicographic order. im keys <bcp14>MUST</bcp14> appear in lexicographic order. Therefore, the claim
Therefore, the claim keys discussed in this document appear in the PASSporT Pay keys discussed in this document appear in the PASSporT Payload in the following
load in the following order,</t> order:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>dest</li>
<t>dest</t> <li>iat</li>
<t>iat</t> <li>orig</li>
<t>orig</t> <li>rph</li>
<t>rph</t> <li>sph</li>
<t>sph</t> </ul>
</list></t> </section>
<section anchor="compact-form-of-passport" numbered="true" toc="default">
</section> <name>Compact Form of PASSporT</name>
<section anchor="compact-form-of-passport" title="Compact Form of PASSporT"> <t>The use of the compact form of PASSporT is not specified in this docume
nt or recommended for "rph" PASSporTs.</t>
<t>The use of the compact form of PASSporT is not specified in this document or </section>
recommended for ‘rph’ PASSporTs.</t> <section anchor="iana-considerations" numbered="true" toc="default">
<name>IANA Considerations</name>
</section> <section anchor="json-web-token-claims" numbered="true" toc="default">
<section anchor="acknowledgements" title="Acknowledgements"> <name>JSON Web Token Claims</name>
<t>This specification requests that the IANA add one new claim to the "J
<t>The authors would like to thank Brian Rosen, Terry Reese, and Jon Peterson fo SON Web Token Claims" registry, as defined in <xref target="RFC7519" format="def
r helpful suggestions, comments, and corrections.</t> ault"/>.</t>
<dl newline="false" spacing="compact">
</section> <dt>Claim Name:</dt>
<section anchor="iana-considerations" title="IANA Considerations"> <dd>sph</dd>
<dt>Claim Description:</dt>
<section anchor="json-web-token-claims" title="JSON Web Token claims"> <dd>SIP Priority header field</dd>
<dt>Change Controller:</dt>
<t>This specification requests that the IANA add one new claim to the JSON Web T <dd>IESG</dd>
oken Claims registry as defined in <xref target="RFC7519"/>.</t> <dt>Specification Document(s):</dt>
<dd>RFC 9027</dd>
<t>Claim Name: “sph”</t> </dl>
</section>
<t>Claim Description: SIP Priority header field</t> </section>
<section anchor="security-considerations" numbered="true" toc="default">
<t>Change Controller: IESG</t> <name>Security Considerations</name>
<t>The security considerations discussed in <xref target="RFC8224" format=
<t>Specification Document(s): [RFCThis]</t> "default"/>, <xref target="RFC8225" format="default"/>, and <xref target="RFC844
3" format="default"/> are applicable here.</t>
</section> </section>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>The security considerations discussed in <xref target="RFC8224"/>, <xref targ
et="RFC8225"/>, and <xref target="RFC8443"/> are applicable here.</t>
</section>
</middle> </middle>
<back> <back>
<references title='Normative References'> <displayreference target="I-D.rosen-stir-emergency-calls" to="EMERGENCY-CALLS"/>
<reference anchor="RFC4412" target='https://www.rfc-editor.org/info/rfc4412'>
<front>
<title>Communications Resource Priority for the Session Initiation Protocol (SIP
)</title>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'><organizat
ion /></author>
<author initials='J.' surname='Polk' fullname='J. Polk'><organization /></author
>
<date year='2006' month='February' />
<abstract><t>This document defines two new Session Initiation Protocol (SIP) hea
der fields for communicating resource priority, namely, &quot;Resource-Priority&
quot; and &quot;Accept-Resource-Priority&quot;. The &quot;Resource-Priority&quo
t; header field can influence the behavior of SIP user agents (such as telephone
gateways and IP telephones) and SIP proxies. It does not directly influence th
e forwarding behavior of IP routers. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4412'/>
<seriesInfo name='DOI' value='10.17487/RFC4412'/>
</reference>
<reference anchor="RFC5031" target='https://www.rfc-editor.org/info/rfc5031'>
<front>
<title>A Uniform Resource Name (URN) for Emergency and Other Well-Known Services
</title>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'><organizat
ion /></author>
<date year='2008' month='January' />
<abstract><t>The content of many communication services depends on the context,
such as the user's location. We describe a 'service' URN that allows well-known
context-dependent services that can be resolved in a distributed manner to be i
dentified. Examples include emergency services, directory assistance, and call-
before-you-dig hot lines. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5031'/>
<seriesInfo name='DOI' value='10.17487/RFC5031'/>
</reference>
<reference anchor="RFC7090" target='https://www.rfc-editor.org/info/rfc7090'>
<front>
<title>Public Safety Answering Point (PSAP) Callback</title>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'><organizat
ion /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'><organizatio
n /></author>
<author initials='C.' surname='Holmberg' fullname='C. Holmberg'><organization />
</author>
<author initials='M.' surname='Patel' fullname='M. Patel'><organization /></auth
or>
<date year='2014' month='April' />
<abstract><t>After an emergency call is completed (terminated either prematurely
by the emergency caller or normally by the call taker), the call taker may feel
the need for further communication. For example, the call may have been droppe
d by accident without the call taker having sufficient information about the cur
rent state of an accident victim. A call taker may trigger a callback to the eme
rgency caller using the contact information provided with the initial emergency
call. This callback could, under certain circumstances, be treated like any oth
er call and, as a consequence, it may get blocked by authorization policies or m
ay get forwarded to an answering machine.</t><t>The IETF emergency services arch
itecture specification already offers a solution approach for allowing Public Sa
fety Answering Point (PSAP) callbacks to bypass authorization policies in order
to reach the caller without unnecessary delays. Unfortunately, the specified me
chanism only supports limited scenarios. This document discusses shortcomings o
f the current mechanisms and illustrates additional scenarios where better-than-
normal call treatment behavior would be desirable. We describe a solution based
on a new header field value for the SIP Priority header field, called &quot;psa
p-callback&quot;, to mark PSAP callbacks.</t></abstract>
</front>
<seriesInfo name='RFC' value='7090'/>
<seriesInfo name='DOI' value='10.17487/RFC7090'/>
</reference>
<reference anchor="RFC7135" target='https://www.rfc-editor.org/info/rfc7135'>
<front>
<title>Registering a SIP Resource Priority Header Field Namespace for Local Emer
gency Communications</title>
<author initials='J.' surname='Polk' fullname='J. Polk'><organization /></author
>
<date year='2014' month='May' />
<abstract><t>This document creates the new Session Initiation Protocol (SIP) Res
ource Priority header field namespace 'esnet' and registers this namespace with
IANA. The new header field namespace allows for local emergency session establi
shment to a public safety answering point (PSAP), between PSAPs, and between a P
SAP and first responders and their organizations.</t></abstract>
</front>
<seriesInfo name='RFC' value='7135'/>
<seriesInfo name='DOI' value='10.17487/RFC7135'/>
</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 initials='J.' surname='Peterson' fullname='J. Peterson'><organization />
</author>
<author initials='C.' surname='Jennings' fullname='C. Jennings'><organization />
</author>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization />
</author>
<author initials='C.' surname='Wendt' fullname='C. Wendt'><organization /></auth
or>
<date year='2018' month='February' />
<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 initials='C.' surname='Wendt' fullname='C. Wendt'><organization /></auth
or>
<author initials='J.' surname='Peterson' fullname='J. Peterson'><organization />
</author>
<date year='2018' month='February' />
<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="RFC7519" target='https://www.rfc-editor.org/info/rfc7519'>
<front>
<title>JSON Web Token (JWT)</title>
<author initials='M.' surname='Jones' fullname='M. Jones'><organization /></auth
or>
<author initials='J.' surname='Bradley' fullname='J. Bradley'><organization /></
author>
<author initials='N.' surname='Sakimura' fullname='N. Sakimura'><organization />
</author>
<date year='2015' month='May' />
<abstract><t>JSON Web Token (JWT) is a compact, URL-safe means of representing c
laims to be transferred between two parties. The claims in a JWT are encoded as
a JSON object that is used as the payload of a JSON Web Signature (JWS) structu
re or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the cl
aims to be digitally signed or integrity protected with a Message Authentication
Code (MAC) and/or encrypted.</t></abstract>
</front>
<seriesInfo name='RFC' value='7519'/>
<seriesInfo name='DOI' value='10.17487/RFC7519'/>
</reference>
<reference anchor="RFC8443" target='https://www.rfc-editor.org/info/rfc8443'>
<front>
<title>Personal Assertion Token (PASSporT) Extension for Resource Priority Autho
rization</title>
<author initials='R.' surname='Singh' fullname='R. Singh'><organization /></auth
or>
<author initials='M.' surname='Dolly' fullname='M. Dolly'><organization /></auth
or>
<author initials='S.' surname='Das' fullname='S. Das'><organization /></author>
<author initials='A.' surname='Nguyen' fullname='A. Nguyen'><organization /></au
thor>
<date year='2018' month='August' />
<abstract><t>This document extends the Personal Assertion Token (PASSporT) speci
fication defined in RFC 8225 to allow the inclusion of cryptographically signed
assertions of authorization for the values populated in the Session Initiation P
rotocol (SIP) 'Resource-Priority' header field, which is used for communications
resource prioritization.</t></abstract>
</front>
<seriesInfo name='RFC' value='8443'/>
<seriesInfo name='DOI' value='10.17487/RFC8443'/>
</reference>
</references>
<references title='Informative References'>
<reference anchor="I-D.rosen-stir-emergency-calls">
<front>
<title>Non-Interactive Emergency Calls</title>
<author initials='B' surname='Rosen' fullname='Brian Rosen'>
<organization />
</author>
<date month='March' day='9' year='2020' />
<abstract><t>Emergency calls from citizens to authorities, and call back of such
emergency calls by authorities to citizens need assurances that headers intende
d to get appropriate priority from the networks they traverse, and in some cases
, appropriate routing. Protection of the SIP Resource Priority Header and the S
IP Priority header is needed for such calls. This document describes the enviro
nment for placing emergency calls and call backs which motivate the need and use
of the mechanisms described in other documents</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-rosen-stir-emergency-calls-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-rosen-stir-emergency-c
alls-00.txt' />
</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 initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></
author>
<date year='1997' month='March' />
<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 initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></auth
or>
<date year='2017' month='May' />
<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>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4412.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5031.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7090.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7135.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8224.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8225.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7519.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8443.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.rosen-stir-emergency-calls.xml"/>
</references>
</references> </references>
<section anchor="acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Brian Rosen"/>, <con
tact fullname="Terry Reese"/>, and <contact fullname="Jon Peterson"/> for helpfu
l suggestions, comments, and corrections.</t>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIAOEkSmAAA81a/27byBH+n0+xUIDGLiTVsp3mov5zOjt38TVxXMvpoQgO
BUWupD1TXHaXtKMLUuQxWqB9uTxJv5ndJSmJcnKHomiAWDS13J0f38x8M/Rg
MIhKVWZyLCbWSlMqnYs/x1klrZhrI2JxLa2uTCLFlVHaqHItXsg4lUacZbFa
iThPsWh6cbXne5WLaVUU2pRCz8XzlTQLmSdrMZXmTiU45VKW99rc2iiezYy8
G4vrqxdtCXYfiVKd5PEKIqcmnpcDJcv5wJbKDEyxHMiwfmD9+sHR0yiNS6w/
PjoeDY5OBqNRlODGQpv1WNgyjaJIFWYsSlPZ8vjo6NnRcRQbGcMo1zcRibcw
uirGYnpzcR3dyjVupWNxkZfS5LIcnJMcUWRLWOOvcaZznLWGoIUai7elTvrC
wgBGzi2u1iu6+DGK4qpcajOOBpGAmexYvBqKc51la/zu9HsVwyF5fVObBSS6
+c0NruUqVtlYrNKT0cmTr+OyHCZ61Wx1NhQ/yDwt663OlkbZ+h7vdKZXSWzL
ZrOE1rA5v+bLe1o9hIJYYiG+LOuHxI1MlrnO9GItziTZAWsSeH8srpYqAwCy
YqnivriaCDF6Njo6oe91lZdk8jfTSRTl2qziUt3JMb66/vbs9HR07C+fHJ2M
/OVTOCNcQlN/+dXx8WlzGe4+fTJ6Fu6enp6MI5XP24dcDM6HRluZO7Q0SEni
LLP+yeNRs8noKU6JBoOBiGcwQJzAyTdL2BEIrFZQW8RpakUu70VcR8/dF0XP
waeP/wJcP33896FIWpFEe3VFk1tz0LPFsnfImxdGlzLhIxFZ5VKKXmHjgpWZ
xcltz0kCyUQRu/DjRTi1B7dMpwjKGyHflTK32KRPoWqbUKW1ViYVC/Fw6LI4
tTUFCQCEqYXKYxaPNAtSDZ09VypNMxlFjyiIjE4rViSKrqSxOo+zVja60bcy
FwdB4kPxPIjM5+5aeMJxpX52h79/7+Hw4YNTNpUpK/clR9lCJmquErdVKucq
x9Mq7AroYddSCyin73lXlSdZZb1TErMuSr0wMWKBDLAWVi1ohxotlpbFGwKT
UrSTx1GhiypDsuJj6f5UWt7/Ilelco9cAQo60Zk4AHQORS/YZBBs0hNLB6O5
klnqpKd4+/BhiF8ejgtoqLyPIA5JkEtSAU79CemyMU8QfBOYM10undxAdZdk
tFGvW1Cky8riLNrZJ2z1s8oX/hjvbywJgGXoeTuVMpPFErkY8jJO+407yRW7
oLUAJ/Ib5F+pZs99cuPxfWJTpoOZM9wjdGA3L6OXRBi/nRUHaiiHfZEizqBX
ovOFtGw6m8g8xvb2EJG5KpB7guJxUWTB5qHGhciFsYA+v3Cf5BtYIPPT4iUu
MnoSYl5VM5wgpqhqEvGUoxKweFcaSEB8TCdAWYhoslo7HDgWbJNYrJitxT0C
YImzAtYppzg31YkC+1uVAvc4a76uld2IDQoWzmYqQVAAFHq1qvJtAH6R3u21
e5YkkJccR/ngipIlJ2FLLu2ObJ8BfNGhzGetThRH771CHEj8kA8LuR9WLo/q
/A4+acoNoxTBG/IFjM2pG+KQDclY600rDoWYhET0K6S4V4gxl/BiADmR6o4O
QjUkrx5wAkzrOwoiZToJCSxV87k0VDlDKKQa5CO3v5uBHKQAvLSHZGCHgpAI
VeqrUCtxUtpNygCjttXZ1DDUHHDKURnKZVzuLFqiLua6FDOJlG8LreeSQZHU
CSAd7q32PTIoUpcx8VqAD/7qor9TUrhQbdfi/1btFTvqKFrE+HWSWE9Ban7A
YvYF846+aJy7yz42WMsGYkJcqjwNoUquzFty+zzGog5IVvK0g2hdC3f4DTy4
bT+iiyhq8Jts1wWoVKuYtvhWy3WJNsjKhc5ZPYAr6PR4Jzwe87OPm183k/+m
R+oMDcvXddQL/NnCO6vgf0oZ91yQqnKg0eokuvCatbyJqL7Ia5f2HcXZSlwk
tle3ZbhyExSGHOV5EqlCZsQqmd8po3NaY5HOEcR0BH7SAysZu4isw9ZHHPvQ
tCHyi80J4ULRYCaPqARtvJFmpVwDErG3yZXUllnRe/VmegOw8qe4fM3X18//
9Obi+vk5XU9fTF6+rC/CiumL129enjdXzZNnr1+9en557h7GXbF169XkL/hg
HvP66ubi9eXkZa/bsLDQzJnXFEaWzAThCpsYNXPO+ObsSoxOHZipFQEIXGJA
L4JrGD53R+k8W/tfYdo1sQKJiogtKAUkcQFzZSBQOMAu9T0SHpw1JNNdIr47
m33XGjBWfObr4r+OA8YzlVGgQ6O68pF7d7wbcp9LBdSMWpAZyQdSYcja2atd
zjuCGw0gEQxobyTsZ6nxTOuKVzJH6UmL0jJ81/MgfUcAavPFQSbvpK9gDavm
pxrxhrBQQO09nvLEqNw1SsfWWDNDeqbCcsTSnvZDX3An+xzUK9QNIKFuSKDD
vCoryLuxO3GrqVop4jo+JW3FLx5sdzgh1foC9f309aXQs5+QqTlAUGiJYjV9
oE/v3fZTnrkDWkZDRxRxn4mBKCK4M+n4OcGw5rQNMYcdjPxbpYzPJJ9x92YG
JrvJd6jwgDlKdrJss9pdlG0UnBod4ZkGdiq/Q5NXu50SLWz8AyngiHOjf2zb
ptxq8Dkl7pSvlMg7lxhK4M6uPSrH3tIBUnV55RRVi1uL1DC3vFrNmDEioSrX
8fkI5FIPUOyWGpQCyog9kiYczAd5+gm3xWEYQ5THyAX3Eh55IGlwk4fDgRwu
0J/0no1GPXbiJTjJUkxwKBzHPHE0Ou6J76avakz6RxkaMNPzylDB4qTF57uj
menR85XJx170sdW2s67TRIh40Y5nOwqtc0Lc5ibezWSVuabAp8epsOSEsVWR
Sc9IaoLmzUYaE+A+ffzHDuY+ffznNjMul34TB6IRbVQDZxxFf2//i4R4j//C
O2r8HpZQvfHbHYP8+KHv1sH5vfHo96Mnp09Hp8df+buMLzxd5r0xjh4dj57g
Hz6Oe+FBinWsYCTjAC8dNsbXH7akir7t5i91v7cf1luzpQ5wf1Fn2ercGf3D
PXCeye1G3wXLDkg8Ic62YstL3c1CfchRKufOHLco3boR1v8ESA2Ojn4hjggJ
b3ttIPwCCLWeO3kYQEd7ADSBc10Z8lpxE+IoaA0OV5Us+rA76ZowdGzIHFWC
ms4QU4apRcxlETaGj6ThRpJHx9S0FP6cRaXSOOf0vjGaa2Yh8woupe6P5xue
F/tEmaBAEVrAl8I85oxMzVVYHrpExk2/pBIYeK0TbFXZ0inRGm3cebmaurMR
Ib7q+tGL0475HIG42aYIc18XAM0XjH7m5TBgW/rteQOLGtJ6QHczKvLMabdy
t+ulS6BOjIu5MAPPQIjPot1wXXOKFF80OzLDXUkUEkrzgl6J+KFdXC77XUvY
jMHDvgl1xlKpHy20wFRTThdcQVcghphubSimuzd7elNuaQPbnexrJT/T2noe
Z8Ed2/xsp1Xd0xOGBX78KMQ3MonJsVav3LF56PPppHreAbz44T6MAXJ2R6yu
9h7OcoWWXY+0Z9A5UiDMYkLyxg5gppzl1IowEeesh2/uQ7+o0gD7jUaMEbiN
OFW69GgkVMbu99Ib1vvUOeyWR1gPvJfwEwcOUGV9htWFm1b4TThBcyhw7AQy
6hojX4o9eWvBhG7WFC9QOTeXYNZZz8qw1eZcpXaUH8RtzQviB2BSB2MnOnxB
cd8FczToZGt5xh003caXm6+yMZgsfwa27iieVnVpu1vzOfQbBdgf65I5ufYj
TTLsplTNEIIzvkcS0bJQvinlA7rUIMRiHquMMmoClMIkl5pe2YaACCmDu6V6
srPTjYVE2h1v/SbdIltqV7VpmI4YAJCrVeFbus7pxRa7SVrTbI4HHNuQnfq1
B1Qs6YbfZO9ssBnxdn+zZ6y88UrD84aHEw1s5zpjFtG9qZDvlC23x4PKDUhr
q7vhReyzdCZWMoHTlV1tvI4EIrreX4b3OeyzJHSPcULj1kzZpRuFhITge2Ee
EHulNqaS9csFynVNWnHliHoi1+iwf5VloRriYbr2qWy8kF/K7OweZvcwoWvC
B1tsRAo2+78idf57SkHjrZju4nuPxGuTujhxf/TxR7m2zpQ6fNEUa2Qz6xKA
s7OjIFUmeeDSZm9TP2B+5tNbe/6UypIngOTdxM05AHYUu/CqqH5x2FA1Ty/o
24NWacPvh3/oFLCZqWXAURLe9zitmJSFMrf1dKpsUlnbOV+t99xIjlfxOtNx
PZdoIMhn9aPot9zX4gPOxk9yLj7gQvyEo8gL9O6SKMK3LZpLm0fb4/DEL5xv
LQwh75NKl/g8LqDBTTMgfgwhHtd70Mjq0SS5zfU9GqaF5IGxk8BlS4uw5rej
6lY60hTnt+Ib+C4X1zQM79Nw16yRKpFKHUv+nl5yk8etf823lFkBSg8uu/Av
TJFbnFil7TcFOglTtEfiYnI5gYlcwXEjJ9x+5LDzg5z5t/+uT+mcf9IwC4fZ
pkDwnsg6wr1mDnnIU8Gtnc9cB0TTFkuTl67XF09o4kuvoXmfS/7THY7DcOuc
h8Vcp8b7CzxWw6oLSfqWBliSZiwunk+/i6Lphkrn3q8H9nAs3kICUvtHMtc0
/O3Htslu2n8Ykmx8uYn7EMqnNLhpxbVzT3tqya2Ee6s9y2SYVNPfiVDOif4D
bYi9B6UmAAA=
</rfc> </rfc>
 End of changes. 23 change blocks. 
552 lines changed or deleted 239 lines changed or added

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