rfc8688xml2.original.xml   rfc8688.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true"
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere docName="draft-ietf-sipcore-rejected-09"
nce.RFC.2119.xml"> ipr="trust200902" number="8688" obsoletes="" sortRefs="true"
<!ENTITY RFC3261 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere submissionType="IETF" symRefs="true" tocInclude="true" updates=""
nce.RFC.3261.xml"> version="3" xml:lang="en">
<!ENTITY RFC3262 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.3262.xml">
<!ENTITY RFC3326 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.3326.xml">
<!ENTITY RFC4103 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.4103.xml">
<!ENTITY RFC4240 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.4240.xml">
<!ENTITY RFC4566 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.4566.xml">
<!ENTITY RFC5039 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.5039.xml">
<!ENTITY RFC6350 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.6350.xml">
<!ENTITY RFC6809 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.6809.xml">
<!ENTITY RFC7092 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.7092.xml">
<!ENTITY RFC7095 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.7095.xml">
<!ENTITY RFC7340 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.7340.xml">
<!ENTITY RFC7515 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.7515.xml">
<!ENTITY RFC7518 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.7518.xml">
<!ENTITY RFC7519 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.7519.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8174.xml">
<!ENTITY RFC8197 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8197.xml">
<!ENTITY RFC8224 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8224.xml">
<!ENTITY RFC8259 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8259.xml">
<!ENTITY RFC8445 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8445.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc submissionType="IETF" category="std" consensus="yes" number="XXXX" ipr="tru
st200902">
<front> <front>
<title abbrev="SIP Response Code for Rejected Calls">A Session Initiation <title abbrev="SIP Response Code for Rejected Calls">A Session Initiation
Protocol (SIP) Response Code for Rejected Calls</title> Protocol (SIP) Response Code for Rejected Calls</title>
<seriesInfo name="RFC" value="8688"/>
<author fullname="Eric W. Burger" initials="E.W." surname="Burger"> <author fullname="Eric W. Burger" initials="E.W." surname="Burger">
<organization>Georgetown University</organization> <organization>Georgetown University</organization>
<address> <address>
<postal> <postal>
<street>37th &amp; O St, NW</street> <street>37th &amp; O St, NW</street>
<city>Washington</city> <city>Washington</city>
<region>DC</region> <region>DC</region>
<code>20057</code> <code>20057</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>eburger@standardstrack.com</email> <email>eburger@standardstrack.com</email>
</address> </address>
</author> </author>
<author fullname="Bhavik Nagda" initials="B." surname="Nagda"> <author fullname="Bhavik Nagda" initials="B." surname="Nagda">
<organization>Massachusetts Institute of Technology</organization> <organization>Massachusetts Institute of Technology</organization>
<address> <address>
<postal> <postal>
<street>77 Massachusetts Avenue</street> <street>77 Massachusetts Avenue</street>
<city>Cambridge</city> <city>Cambridge</city>
<region>MA</region> <region>MA</region>
<code>02139</code> <code>02139</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<phone/> <phone/>
<facsimile/>
<email>nagdab@gmail.com</email> <email>nagdab@gmail.com</email>
<uri/> <uri/>
</address> </address>
</author> </author>
<!-- If the month and year are both specified and are the current ones, xml2 <date month="December" year="2019"/>
rfc will fill
in the current day for you. If only the current year is specified, xml2r
fc will fill
in the current day and month for you. If the year is not the current one
, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not sp
ecified for the
purpose of calculating the expiry date). With drafts it is normally suf
ficient to
specify just the year. -->
<date month="September" year="2019"/>
<!-- Meta-data Declarations -->
<area>RAI</area> <area>RAI</area>
<workgroup>SIPCORE</workgroup> <workgroup>SIPCORE</workgroup>
<keyword>STIR</keyword> <keyword>STIR</keyword>
<keyword>SIPCORE</keyword> <keyword>SIPCORE</keyword>
<keyword>IANA</keyword> <keyword>IANA</keyword>
<abstract> <abstract>
<t>This document defines the 608 (Rejected) SIP response code. This <t>This document defines the 608 (Rejected) Session Initiation Protocol
response code enables calling parties to learn that an intermediary (SIP) response code. This response code enables calling parties to learn
rejected their call attempt. No one will deliver, and thus no one will that an intermediary rejected their call attempt. No one will deliver,
answer, the call. As a 6xx code, the caller will be aware that future and thus answer, the call. As a 6xx code, the caller will be aware that
attempts to contact the same User Agent Server will likely fail. The future attempts to contact the same User Agent Server will likely fail.
initial use case driving the need for the 608 response code is when the The initial use case driving the need for the 608 response code is when
intermediary is an analytics engine. In this case, the rejection is by a the intermediary is an analytics engine. In this case, the rejection is
machine or other process. This contrasts with the 607 (Unwanted) SIP by a machine or other process. This contrasts with the 607 (Unwanted)
response code, which a human at the target User Agent Server indicated SIP response code in which a human at the target User Agent Server
the user did not want the call. In some jurisdictions this distinction indicates the user did not want the call. In some jurisdictions, this
is important. This document also defines the use of the Call-Info header distinction is important. This document also defines the use of the
field in 608 responses to enable rejected callers to contact entities Call-Info header field in 608 responses to enable rejected callers to
that blocked their calls in error. This provides a remediation mechanism contact entities that blocked their calls in error. This provides a
for legal callers that find their calls blocked.</t> remediation mechanism for legal callers that find their calls
blocked.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<name>Introduction</name>
<t>The IETF has been addressing numerous issues surrounding how to <t>The IETF has been addressing numerous issues surrounding how to
handle unwanted and, depending on the jurisdiction, illegal calls <xref handle unwanted and, depending on the jurisdiction, illegal calls <xref
target="RFC5039"/>. <xref target="RFC7340">STIR</xref> and <xref format="default" target="RFC5039"/>. Secure Telephone Identity Revisited
target="SHAKEN">SHAKEN</xref> address the cryptographic signing and (STIR) <xref format="default" target="RFC7340"/> and Signature-based
Handling of Asserted information using toKENs (SHAKEN) <xref
format="default" target="SHAKEN"/> address the cryptographic signing and
attestation, respectively, of signaling to ensure the integrity and attestation, respectively, of signaling to ensure the integrity and
authenticity of the asserted caller identity.</t> authenticity of the asserted caller identity.</t>
<t>This document describes a new <xref target="RFC3261">Session <t>This document describes a new <xref format="default"
Initiation Protocol (SIP)</xref> response code, 608, which allows target="RFC3261">Session Initiation Protocol (SIP)</xref> response code,
calling parties to learn that an intermediary rejected their call. As 608, which allows calling parties to learn that an intermediary rejected
described below, we need a distinct indicator to differentiate between a their call. As described below, we need a distinct indicator to
user rejection and an intermediary's rejection of a call. In some differentiate between a user rejection and an intermediary's rejection
jurisdictions, service providers may not be permitted to block calls, of a call. In some jurisdictions, service providers may not be permitted
even if unwanted by the user, unless there is an explicit user request. to block calls, even if unwanted by the user, unless there is an
Moreover, users may misidentify the nature of a caller.</t> explicit user request. Moreover, users may misidentify the nature of a
caller.</t>
<t>For example, a legitimate caller may call a user who finds the call <t>For example, a legitimate caller may call a user who finds the call
to be unwanted. However, instead of marking the call as unwanted, the to be unwanted. However, instead of marking the call as unwanted, the
user may mark the call as illegal. With that information, an analytics user may mark the call as illegal. With that information, an analytics
engine may determine to block all calls from that source. However, in engine may determine to block all calls from that source. However, in
some jurisdictions blocking calls from that source for other users may some jurisdictions, blocking calls from that source for other users may
not be legal. Likewise, one can envision jurisdictions that allow an not be legal. Likewise, one can envision jurisdictions that allow an
operator to block such calls, but only if there is a remediation operator to block such calls, but only if there is a remediation
mechanism in place to address false positives.</t> mechanism in place to address false positives.</t>
<t>Some call blocking services may return responses such as 604 (Does <t>Some call-blocking services may return responses such as 604 (Does
Not Exist Anywhere). This might be a strategy to try to get a Not Exist Anywhere). This might be a strategy to try to get a
destination's address removed from a calling database. However, other destination's address removed from a calling database. However, other
network elements might also interpret this to mean the user truly does network elements might also interpret this to mean the user truly does
not exist, which might result in the user not being able to receive not exist, which might result in the user not being able to receive
calls from anyone, even if they wanted to receive the calls. In many calls from anyone, even if they wanted to receive the calls. In many
jurisdictions, providing such false signaling is also illegal.</t> jurisdictions, providing such false signaling is also illegal.</t>
<t>The 608 response code addresses this need of remediating falsely <t>The 608 response code addresses this need of remediating falsely
blocked calls. Specifically, this code informs the SIP User Agent Client blocked calls. Specifically, this code informs the SIP User Agent Client
(UAC) that an intermediary blocked the call and provides a redress (UAC) that an intermediary blocked the call and provides a redress
mechanism that allows callers to contact the operator of the mechanism that allows callers to contact the operator of the
intermediary.</t> intermediary.</t>
<t>In the current call handling ecosystem, users can explicitly reject a <t>In the current call handling ecosystem, users can explicitly reject a
call or later mark a call as being unwanted by issuing a <xref call or later mark a call as being unwanted by issuing a <xref
target="RFC8197">607 SIP response code (Unwanted)</xref>. <xref format="default" target="RFC8197">607 SIP response code
target="uas_reject"/> and <xref target="reject_ladder"/> show the (Unwanted)</xref>. Figures <xref format="counter" target="uas_reject"/>
operation of the 607 SIP response code. The User Agent Server (UAS) and <xref format="counter" target="reject_ladder"/> show the operation
indicates the call was unwanted. As <xref target="RFC8197"/> explains, of the 607 SIP response code. The User Agent Server (UAS) indicates the
not only does the called party desire to reject that call, they can let call was unwanted. As <xref format="default" target="RFC8197"/>
their proxy know that they consider future calls from that source explains, not only does the called party desire to reject that call,
unwanted. Upon receipt of the 607 response from the UAS, the proxy may they can let their proxy know that they consider future calls from that
send unwanted call indicators, such as the value of the From header source unwanted. Upon receipt of the 607 response from the UAS, the
field and other information elements, to a call analytics engine. For proxy may send unwanted call indicators, such as the value of the From
various reasons described in <xref target="RFC8197"/>, if a network header field and other information elements, to a call analytics engine.
operator receives multiple reports of unwanted calls, that may indicate For various reasons described in <xref format="default"
that the entity placing the calls is likely to be a source of unwanted target="RFC8197"/>, if a network operator receives multiple reports of
calls for many people. As such, other customers of the service provider unwanted calls, that may indicate that the entity placing the calls is
may want the service provider to automatically reject calls on their likely to be a source of unwanted calls for many people. As such, other
behalf.</t> customers of the service provider may want the service provider to
automatically reject calls on their behalf.</t>
<t>There is another value of the 607 rejection code. Presuming the proxy <t>There is another value of the 607 rejection code. Presuming the proxy
forwards the response code to the User Agent Client (UAC), the calling forwards the response code to the UAC, the calling UAC or intervening
UAC or intervening proxies will also learn the user is not interested in proxies will also learn the user is not interested in receiving calls
receiving calls from that sender.</t> from that sender.</t>
<figure anchor="uas_reject" title="Unwanted (607) Call Flow"> <figure anchor="uas_reject">
<artwork><![CDATA[ <name>Unwanted (607) Call Flow</name>
+-----------+
| Call |
| Analytics |
| Engine |
+-----------+
^ | (likely not SIP)
| v
+-----------+
+-----+ 607 | Called | 607 +-----+
| UAC | <--------- | Party | <-------- | UAS |
+-----+ | Proxy | +-----+
+-----------+
]]></artwork> <artwork align="center" alt="" name="" type="ascii-art"><![CDATA[
+-----------+
| Call |
| Analytics |
| Engine |
+-----------+
^ | (likely not SIP)
| v
+-----------+
+-----+ 607 | Called | 607 +-----+
| UAC | <--------- | Party | <-------- | UAS |
+-----+ | Proxy | +-----+
+-----------+
]]></artwork>
</figure> </figure>
<t>For calls rejected with a 607 from a legitimate caller, receiving a <t>For calls rejected with a 607 from a legitimate caller, receiving a
607 response code can inform the caller to stop attempting to call the 607 response code can inform the caller to stop attempting to call the
user. Moreover, if a legitimate caller believes the user is rejecting user. Moreover, if a legitimate caller believes the user is rejecting
their calls in error, they can use other channels to contact the user. their calls in error, they can use other channels to contact the user.
For example, if a pharmacy calls a user to let them know their For example, if a pharmacy calls a user to let them know their
prescription is available for pickup and the user mistakenly thinks the prescription is available for pickup and the user mistakenly thinks the
call is unwanted and issues a 607 response code, the pharmacy, having an call is unwanted and issues a 607 response code, the pharmacy, having an
existing relationship with the customer, can send the user an email or existing relationship with the customer, can send the user an email or
skipping to change at line 227 skipping to change at line 195
<t>Many systems that allow the user to mark the call unwanted (e.g., <t>Many systems that allow the user to mark the call unwanted (e.g.,
with the 607 response code) also allow the user to change their mind and with the 607 response code) also allow the user to change their mind and
unmark such calls. This mechanism is relatively easy to implement as the unmark such calls. This mechanism is relatively easy to implement as the
user usually has a direct relationship with the service provider that is user usually has a direct relationship with the service provider that is
blocking calls.</t> blocking calls.</t>
<t>However, things become more complicated if an intermediary, such as a <t>However, things become more complicated if an intermediary, such as a
third-party provider of call management services that classifies calls third-party provider of call management services that classifies calls
based on the relative likelihood that the call is unwanted, based on the relative likelihood that the call is unwanted,
misidentifies the call as unwanted. <xref target="cae_reject"/> shows misidentifies the call as unwanted. <xref format="default"
this case. Note that the UAS typically does not receive an INVITE since target="cae_reject"/> shows this case. Note that the UAS typically does
the called party proxy rejects the call on behalf of the user. In this not receive an INVITE since the called party proxy rejects the call on
situation, it would be beneficial for the caller to learn who rejected behalf of the user. In this situation, it would be beneficial for the
the call, so they can correct the misidentification.</t> caller to learn who rejected the call so they can correct the
misidentification.</t>
<figure anchor="reject_ladder" title="Unwanted (607) Ladder Diagram"> <figure anchor="reject_ladder">
<artwork><![CDATA[ <name>Unwanted (607) Ladder Diagram</name>
+--------+ +-----------+
| Called | | Call |
+-----+ | Party | | Analytics | +-----+
| UAC | | Proxy | | Engine | | UAS |
+-----+ +--------+ +-----------+ +-----+
| INVITE | | |
| --------------> | Is call OK? | |
| |------------------->| |
| | | |
| | Yes | |
| |<-------------------| |
| | | |
| | INVITE | |
| | ------------------------------> |
| | | |
| | | 607 |
| | <------------------------------ |
| | | |
| | Unwanted call | |
| 607 | -----------------> | |
| <-------------- | indicators | |
| | | |
<artwork align="center" alt="" name="" type="call-flow"><![CDATA[
+--------+ +-----------+
| Called | | Call |
+-----+ | Party | | Analytics | +-----+
| UAC | | Proxy | | Engine | | UAS |
+-----+ +--------+ +-----------+ +-----+
| INVITE | | |
| --------------> | Is call OK? | |
| |------------------->| |
| | | |
| | Yes | |
| |<-------------------| |
| | | |
| | INVITE | |
| | ------------------------------> |
| | | |
| | | 607 |
| | <------------------------------ |
| | | |
| | Unwanted call | |
| 607 | -----------------> | |
| <-------------- | indicators | |
| | | |
]]></artwork> ]]></artwork>
</figure> </figure>
<figure anchor="cae_reject" title="Rejected (608) Call Flow"> <figure anchor="cae_reject">
<artwork><![CDATA[ <name>Rejected (608) Call Flow</name>
<artwork align="center" alt="" name="" type="ascii-art"><![CDATA[
+-----------+ +-----------+
| Call | | Call |
| Analytics | | Analytics |
| Engine | | Engine |
+-----------+ +-----------+
^ | (likely not SIP) ^ | (likely not SIP)
| v | v
+-----------+ +-----------+
+-----+ 608 | Called | +-----+ +-----+ 608 | Called | +-----+
| UAC | <--------- | Party | | UAS | | UAC | <--------- | Party | | UAS |
+-----+ | Proxy | +-----+ +-----+ | Proxy | +-----+
+-----------+ +-----------+
]]></artwork>
]]></artwork>
</figure> </figure>
<t>In this situation, one might consider to have the intermediary use <t>In this situation, one might consider having the intermediary use the
the 607 response code. 607 indicates to the caller the subscriber does 607 response code. 607 indicates to the caller that the subscriber does
not want the call. However, <xref target="RFC8197"/> specifies that one not want the call. However, <xref format="default" target="RFC8197"/>
of the uses of 607 is to inform analytics engines that a user (human) specifies that one of the uses of 607 is to inform analytics engines
has rejected a call. The problem here is that network elements that a user (human) has rejected a call. The problem here is that
downstream from the intermediary might interpret the 607 as coming from network elements downstream from the intermediary might interpret the
a user (human) who has marked the call as unwanted, as opposed to coming 607 as coming from a user (human) who has marked the call as unwanted,
from an algorithm using statistics or machine learning to reject the as opposed to coming from an algorithm using statistics or machine
call. An algorithm can be vulnerable to the <xref target="BaseRate">base learning to reject the call. An algorithm can be vulnerable to the
rate fallacy</xref> rejecting the call. In other words, those downstream base-rate fallacy <xref format="default" target="BaseRate"/> rejecting
entities should not rely on another entity 'deciding' the call is the call. In other words, those downstream entities should not rely on
unwanted. By distinguishing between a (human) user rejection and an another entity "deciding" the call is unwanted. By distinguishing
intermediary engine's statistical rejection, a downstream network between a (human) user rejection and an intermediary engine's
element that sees a 607 response code can weigh it as a human rejection statistical rejection, a downstream network element that sees a 607
in its call analytics, versus deciding whether to consider a 608 at all, response code can weigh it as a human rejection in its call analytics,
and if so, weighing it appropriately.</t> versus deciding whether to consider a 608 at all, and if so, weighing it
appropriately.</t>
<t>It is useful for blocked callers to have a redress mechanism. One can <t>It is useful for blocked callers to have a redress mechanism. One can
imagine that some jurisdictions will require it. However, we must be imagine that some jurisdictions will require it. However, we must be
mindful that most of the calls that intermediaries block will, in fact, mindful that most of the calls that intermediaries block will, in fact,
be illegal and eligible for blocking. Thus, providing alternate contact be illegal and eligible for blocking. Thus, providing alternate contact
information for a user would be counterproductive to protecting that information for a user would be counterproductive to protecting that
user from illegal communications. This is another reason we do not user from illegal communications. This is another reason we do not
propose to simply allow alternate contact information in a 607 response propose to simply allow alternate contact information in a 607 response
message.</t> message.</t>
<t>Why do we not use the same mechanism an analytics service provider <t>Why do we not use the same mechanism an analytics service provider
offers their customers? Specifically, why not have the analytics service offers their customers? Specifically, why not have the analytics service
provider allow the called party to correct a call blocked in error? The provider allow the called party to correct a call blocked in error? The
reason is while there is an existing relationship between the customer reason is that while there is an existing relationship between the
(called party) and the analytics service provider, it is unlikely there customer (called party) and the analytics service provider, it is
is a relationship between the caller and the analytics service provider. unlikely there is a relationship between the caller and the analytics
Moreover, there are numerous call blocking providers in the ecosystem. service provider. Moreover, there are numerous call blocking providers
Therefore, we need a mechanism for indicating an intermediary rejected a in the ecosystem. Therefore, we need a mechanism for indicating an
call that also provides contact information for the operator of that intermediary rejected a call that also provides contact information for
intermediary, without exposing the target user's contact the operator of that intermediary without exposing the target user's
information.</t> contact information.</t>
<t>The protocol described in this document uses existing SIP protocol <t>The protocol described in this document uses existing SIP protocol
mechanisms for specifying the redress mechanism. In the Call-Info header mechanisms for specifying the redress mechanism. In the Call-Info header
passed back to the UAC, we send additional information specifying a field passed back to the UAC, we send additional information specifying
redress address. We choose to encode the redress address using <xref a redress address. We choose to encode the redress address using <xref
target="RFC7095">jCard</xref>. As we will see later in this document, format="default" target="RFC7095">jCard</xref>. As we will see later in
this information needs to have its own, application-layer integrity this document, this information needs to have its own application-layer
protection. Thus, we use jCard rather than <xref integrity protection. Thus, we use jCard rather than <xref
target="RFC6350">vCard</xref> as we have a marshaling mechanism for format="default" target="RFC6350">vCard</xref>, as we have a marshaling
creating a JavaScript Object Notation <xref mechanism for creating a JavaScript Object Notation <xref
target="RFC8259">(JSON)</xref> object, such as a jCard, and a standard format="default" target="RFC8259">(JSON)</xref> object, such as a jCard,
integrity format for such an object, namely JSON Web Signature <xref and a standard integrity format for such an object, namely, JSON Web
target="RFC7515">(JWS)</xref>. The SIP community is familiar with this Signature <xref format="default" target="RFC7515">(JWS)</xref>. The SIP
concept as it is the mechanism used by <xref community is familiar with this concept as it is the mechanism used by
target="RFC8224">STIR</xref>.</t> <xref format="default" target="RFC8224">STIR</xref>.</t>
<t>Integrity protecting the jCard with a cryptographic signature might <t>Integrity protecting the jCard with a cryptographic signature might
seem unnecessary at first, but it is essential to preventing potential seem unnecessary at first, but it is essential to preventing potential
network attacks. <xref target="Security"/> describes the attack and why network attacks. <xref format="default" target="Security"/> describes
we sign the jCard in more detail.</t> the attack and why we sign the jCard in more detail.</t>
</section>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
<xref target="RFC2119"/><xref target="RFC8174"/> when, and only when,
they appear in all capitals, as shown here.</t>
</section> </section>
<section title="Protocol Operation"> <section numbered="true" toc="default">
<t>This section uses the term 'intermediary' to mean the entity that <name>Terminology</name>
acts as a SIP User Agent Server (UAS) on behalf of the user in the
network, as opposed to the user's UAS (usually, but not necessarily,
their phone). The intermediary could be a back-to-back user agent
(B2BUA) or a SIP Proxy.</t>
<t><xref target="cae_ladder"/> shows an overview of the call flow for a <t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
rejected call.</t> "<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 "<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>
<figure anchor="cae_ladder" title="Rejected (608) Ladder Diagram"> <section numbered="true" toc="default">
<artwork><![CDATA[ <name>Protocol Operation</name>
+--------+ +-----------+
| Called | | Call |
+-----+ | Party | | Analytics | +-----+
| UAC | | Proxy | | Engine | | UAS |
+-----+ +--------+ +-----------+ +-----+
| INVITE | | |
| --------------> | Information from | |
| | -----------------> | |
| | INVITE | |
| | Reject | |
| 608 | <----------------- | |
| <-------------- | call | |
| | | |
]]></artwork> <t>This section uses the term "intermediary" to mean the entity that
acts as a SIP UAS on behalf of the user in the network as opposed to the
user's UAS (usually, but not necessarily, their phone). The intermediary
could be a back-to-back user agent (B2BUA) or a SIP Proxy.</t>
<t><xref format="default" target="cae_ladder"/> shows an overview of the
call flow for a rejected call.</t>
<figure anchor="cae_ladder">
<name>Rejected (608) Ladder Diagram</name>
<artwork align="center" alt="" name="" type="call-flow"><![CDATA[
+--------+ +-----------+
| Called | | Call |
+-----+ | Party | | Analytics | +-----+
| UAC | | Proxy | | Engine | | UAS |
+-----+ +--------+ +-----------+ +-----+
| INVITE | | |
| --------------> | Is call OK? | |
| |------------------->| |
| | | |
| | Yes | |
| |<-------------------| |
| | | |
| | INVITE | |
| | ------------------------------> |
| | | |
| | | 607 |
| | <------------------------------ |
| | | |
| | Unwanted call | |
| 607 | -----------------> | |
| <-------------- | indicators | |
| | | |
]]></artwork>
</figure> </figure>
<section numbered="true" toc="default">
<section title="Intermediary Operation"> <name>Intermediary Operation</name>
<t>An intermediary MAY issue the 608 response code in a failure <t>An intermediary <bcp14>MAY</bcp14> issue the 608 response code in a
response for an INVITE, MESSAGE, SUBSCRIBE, or other out-of-dialog failure response for an INVITE, MESSAGE, SUBSCRIBE, or other
<xref target="RFC3261">SIP</xref> request to indicate that an out-of-dialog <xref format="default" target="RFC3261">SIP</xref>
intermediary rejected the offered communication as unwanted by the request to indicate that an intermediary rejected the offered
user. An intermediary MAY issue the 608 as the value of the "cause" communication as unwanted by the user. An intermediary
parameter of a SIP reason-value in a Reason header field <xref <bcp14>MAY</bcp14> issue the 608 as the value of the "cause" parameter
of a SIP reason-value in a Reason header field <xref format="default"
target="RFC3326"/>.</t> target="RFC3326"/>.</t>
<t>If an intermediary issues a 608 code and there are no indicators <t>If an intermediary issues a 608 code and there are no indicators
the calling party will use the contents of the Call-Info header field the calling party will use the contents of the Call-Info header field
for malicious purposes (see <xref target="Security"/>), the for malicious purposes (see <xref format="default"
intermediary MUST include a Call-Info header field in the target="Security"/>), the intermediary <bcp14>MUST</bcp14> include a
response.</t> Call-Info header field in the response.</t>
<t>If there is a Call-Info header field, it MUST have the 'purpose' <t>If there is a Call-Info header field, it <bcp14>MUST</bcp14> have
parameter of 'jwscard'. The value of the Call-Info header field MUST the "purpose" parameter of "jwscard". The value of the Call-Info
refer to a valid JSON Web Signature (<xref header field <bcp14>MUST</bcp14> refer to a valid JSON Web Signature
target="RFC7515">JWS</xref>) encoding of a <xref (JWS) <xref format="default" target="RFC7515"/> encoding of a <xref
target="RFC7095">jCard</xref> object. The following section describes format="default" target="RFC7095">jCard</xref> object. The following
the construction of the JWS.</t> section describes the construction of the JWS.</t>
<t>Proxies need to be mindful that a downstream intermediary may <t>Proxies need to be mindful that a downstream intermediary may
reject the attempt with a 608 while other paths may still be in reject the attempt with a 608 while other paths may still be in
progress. In this situation, the requirements stated in Section 16.7 progress. In this situation, the requirements stated in <xref
of <xref target="RFC3261"/> apply. Specifically, the proxy should section="16.7" sectionFormat="of" target="RFC3261"/> apply.
cancel pending transactions and must not create any new branches. Note Specifically, the proxy should cancel pending transactions and must
this is not a new requirement but simply pointing out the existing 6xx not create any new branches. Note this is not a new requirement but
protocol mechanism in SIP.</t> simply pointing out the existing 6xx protocol mechanism in SIP.</t>
</section> </section>
<section title="JWS Construction"> <section numbered="true" toc="default">
<name>JWS Construction</name>
<t>The intermediary constructs the JWS of the jCard as follows.</t> <t>The intermediary constructs the JWS of the jCard as follows.</t>
<section title="JOSE Header"> <section numbered="true" toc="default">
<t>The Javascript Object Signing and Encryption (JOSE) header MUST <name>JOSE Header</name>
include the typ, alg, and x5u parameters from <xref
target="RFC7515">JWS</xref>. The typ parameter MUST have the value <t>The Javascript Object Signing and Encryption (JOSE) header
"vcard+json". Implementations MUST support ES256 as JSON Web <bcp14>MUST</bcp14> include the typ, alg, and x5u parameters from
Algorithms (<xref target="RFC7518">JWA</xref>) defines it, and MAY <xref format="default" target="RFC7515">JWS</xref>. The typ
support other registered signature algorithms. Finally, the x5u parameter <bcp14>MUST</bcp14> have the value "vcard+json".
parameter MUST be a URI that resolves to the public key certificate Implementations <bcp14>MUST</bcp14> support ES256 as JSON Web
corresponding to the key used to digitally sign the JWS.</t> Algorithms (JWA) <xref format="default" target="RFC7518"/> defines
it and <bcp14>MAY</bcp14> support other registered signature
algorithms. Finally, the x5u parameter <bcp14>MUST</bcp14> be a URI
that resolves to the public key certificate corresponding to the key
used to digitally sign the JWS.</t>
</section> </section>
<section anchor="JWT" title="JWT Payload"> <section anchor="JWT" numbered="true" toc="default">
<name>JWT Payload</name>
<t>The payload contains two JSON values. The first JSON Web Token <t>The payload contains two JSON values. The first JSON Web Token
(JWT) claim that MUST be present is the <xref target="RFC7519">iat (JWT) claim that <bcp14>MUST</bcp14> be present is the <xref
(issued at) claim</xref>. The "iat" MUST be set to the date and time format="default" target="RFC7519">"iat" (issued at) claim</xref>.
of the issuance of the 608 response. This mandatory component The "iat" <bcp14>MUST</bcp14> be set to the date and time of the
protects the response from replay attacks.</t> issuance of the 608 response. This mandatory component protects the
response from replay attacks.</t>
<t>The second JWT claim that MUST be present is the "jcard" claim. <t>The second JWT claim that <bcp14>MUST</bcp14> be present is the
The value of the <xref target="RFC7095">jcard</xref> claim is a JSON "jcard" claim. The value of the <xref format="default"
array conforming to the JSON jCard data format defined in RFC7095 target="RFC7095">jcard</xref> claim is a JSON array conforming to
<xref target="JWT-IANA"/> describes the registration. In the the JSON jCard data format defined in <xref target="RFC7095"/>. <xref
construction of the jcard claim, the "jcard" MUST include at least format="default" target="JWT-IANA"/> describes the registration. In
one of the URL, EMAIL, TEL, or ADR properties. UACs supporting this the construction of the jcard claim, the "jcard" <bcp14>MUST</bcp14>
specification MUST be prepared to receive a full jCard. Call include at least one of the URL, EMAIL, TEL, or ADR properties. UACs
originators (at the UAC) can use the information returned by the supporting this specification <bcp14>MUST</bcp14> be prepared to
jCard to contact the intermediary that rejected the call to appeal receive a full jCard. Call originators (at the UAC) can use the
the intermediary's blocking of the call attempt. What the information returned by the jCard to contact the intermediary that
intermediary does if the blocked caller contacts the intermediary is rejected the call to appeal the intermediary's blocking of the call
outside the scope of this document.</t> attempt. What the intermediary does if the blocked caller contacts
the intermediary is outside the scope of this document.</t>
</section> </section>
<section anchor="s.JWS" title="JWS Signature"> <section anchor="s.JWS" numbered="true" toc="default">
<t><xref target="RFC7515">JWS</xref> specifies the procedure for <name>JWS Signature</name>
calculating the signature over the jCard JWT. <xref
target="EXAMPLES"/> of this document has a detailed example on <t><xref format="default" target="RFC7515">JWS</xref> specifies the
constructing the JWS, including the signature.</t> procedure for calculating the signature over the jCard JWT. <xref
format="default" target="EXAMPLES"/> of this document has a detailed
example on constructing the JWS, including the signature.</t>
</section> </section>
</section> </section>
<section title="UAC Operation"> <section numbered="true" toc="default">
<t>A UAC conforming to this specification MUST include the sip.608 <name>UAC Operation</name>
feature capability indicator in the Feature-Caps header field of the
INVITE request.</t> <t>A UAC conforming to this specification <bcp14>MUST</bcp14> include
the sip.608 feature-capability indicator in the Feature-Caps header
field of the INVITE request.</t>
<t>Upon receiving a 608 response, UACs perform normal SIP processing <t>Upon receiving a 608 response, UACs perform normal SIP processing
for 6xx responses.</t> for 6xx responses.</t>
<t>As for the disposition of the jCard itself, the UAC MUST check the <t>As for the disposition of the jCard itself, the UAC
"iat" claim in the JWT. As noted in <xref target="s.JWS"/>, we are <bcp14>MUST</bcp14> check the "iat" claim in the JWT. As noted in
concerned about replay attacks. Therefore, the UAC MUST reject jCards <xref format="default" target="JWT"/>, we are concerned about replay
that come with an expired "iat". The definition of "expired" is a attacks. Therefore, the UAC <bcp14>MUST</bcp14> reject jCards that
matter of local policy. A reasonable value would be on the order of a come with an expired "iat". The definition of "expired" is a matter of
minute due to clock drift and the possibility of the playing of an local policy. A reasonable value would be on the order of a minute due
audio announcement before the delivery of the 608 response.</t> to clock drift and the possibility of the playing of an audio
announcement before the delivery of the 608 response.</t>
</section> </section>
<section title="Legacy Interoperation"> <section numbered="true" toc="default">
<name>Legacy Interoperation</name>
<t>If the UAC indicates support for 608 and the intermediary issues a <t>If the UAC indicates support for 608 and the intermediary issues a
608, life is good, as the UAC will receive all the information it 608, life is good, as the UAC will receive all the information it
needs to remediate an erroneous block by an intermediary. However, needs to remediate an erroneous block by an intermediary. However,
what if the UAC does not understand 608? For example, how can we what if the UAC does not understand 608? For example, how can we
support callers from a legacy, non-SIP public switched network support callers from a legacy, non-SIP, public-switched network
connecting to the SIP network via a media gateway?</t> connecting to the SIP network via a media gateway?</t>
<t>We address this situation by having the first network element that <t>We address this situation by having the first network element that
conforms with this specification play an announcement in the media. conforms with this specification play an announcement. See <xref
See <xref target="announcement"/> for requirements on the format="default" target="announcement"/> for requirements on the
announcement. The simple rule is a network element that inserts the announcement. The simple rule is a network element that inserts the
sip.608 feature capability MUST be able to convey at a minimum how to sip.608 feature capability <bcp14>MUST</bcp14> be able to convey at a
contact the operator of the intermediary that rejected the call minimum how to contact the operator of the intermediary that rejected
attempt.</t> the call attempt.</t>
<t>The degenerate case is the intermediary is the only element that <t>The degenerate case is the intermediary is the only element that
understands the semantics of the 608 response code. Obviously, any SIP understands the semantics of the 608 response code. Obviously, any SIP
device will understand that a 608 response code is a 6xx error. device will understand that a 608 response code is a 6xx error.
However, there are no other elements in the call path that understand However, there are no other elements in the call path that understand
the meaning of the value of the Call-Info header field. The the meaning of the value of the Call-Info header field. The
intermediary knows this is the case as the INVITE request will not intermediary knows this is the case as the INVITE request will not
have the sip.608 feature capability. In this case, one can consider have the sip.608 feature capability. In this case, one can consider
the intermediary to be the element 'inserting' a virtual sip.608 the intermediary to be the element "inserting" a virtual sip.608
feature capability. If the caveats described in <xref feature capability. If the caveats described in Sections <xref
target="announcement"/> and <xref target="Security"/> do not hold, the format="counter" target="announcement"/> and <xref format="counter"
intermediary MUST play the announcement.</t> target="Security"/> do not hold, the intermediary <bcp14>MUST</bcp14>
play the announcement.</t>
<t>Now we take the case where a network element that understands the <t>Now we take the case where a network element that understands the
608 response code receives an INVITE for further processing. A network 608 response code receives an INVITE for further processing. A network
element conforming with this specification MUST insert the sip.608 element conforming with this specification <bcp14>MUST</bcp14> insert
feature capability, per the behaviors described in Section 4.2 of the sip.608 feature capability per the behaviors described in <xref
<xref target="RFC6809"/>.</t> section="4.2" sectionFormat="of" target="RFC6809"/>.</t>
<t>Do note that even if a network element plays an announcement <t>Do note that even if a network element plays an announcement
describing the contents of the 608 response message, the network describing the contents of the 608 response message, the network
element MUST forward the 608 response code message as the final element <bcp14>MUST</bcp14> forward the 608 response code message as
response to the INVITE.</t> the final response to the INVITE.</t>
<t>One aspect of using a feature capability is that only the network <t>One aspect of using a feature capability is that only the network
elements that will either consume (UAC) or play an announcement (media elements that will either consume (UAC) or play an announcement (media
gateway, session border controller (<xref gateway, session border controller (SBC) <xref format="default"
target="RFC7092">SBC</xref>), or proxy) need to understand the sip.608 target="RFC7092"/>, or proxy) need to understand the sip.608 feature
feature capability. If the other network elements conform to Section capability. If the other network elements conform to <xref
16.6 of <xref target="RFC3261"/>, they will pass header fields such as section="16.6" sectionFormat="of" target="RFC3261"/>, they will pass
"Feature-Caps: *;+sip.608" unmodified and without need for header fields such as "Feature-Caps: *;+sip.608" unmodified and
upgrade.</t> without need for upgrade.</t>
<t>Because the ultimate disposition of the call attempt will be a <t>Because the ultimate disposition of the call attempt will be a
600-class response, the network element conveying the announcement in 600-class response, the network element conveying the announcement in
the legacy direction MUST use the 183 Session Progress response to the legacy direction <bcp14>MUST</bcp14> use the 183 Session Progress
establish the media session. Because of the small chance the UAC is an response to establish the media session. Because of the small chance
extremely old legacy device and is using UDP, the UAC MUST include the UAC is an extremely old legacy device and is using UDP, the UAC
support for <xref target="RFC3262">100Rel</xref> in its INVITE and the <bcp14>MUST</bcp14> include support for <xref format="default"
network element conveying the announcement MUST Require 100Rel in the target="RFC3262">100rel</xref> in its INVITE, the network element
183 and the UAC MUST issue a PRACK to which the network element MUST conveying the announcement <bcp14>MUST</bcp14> Require 100rel in the
respond 200 OK PRACK.</t> 183, and the UAC <bcp14>MUST</bcp14> issue a Provisional Response
ACKnowledgement (PRACK) to which the network element
<bcp14>MUST</bcp14> respond 200 OK PRACK.</t>
</section> </section>
<section anchor="announcement" title="Announcement Requirements"> <section anchor="announcement" numbered="true" toc="default">
<name>Announcement Requirements</name>
<t>There are a few requirements on the element that handles the <t>There are a few requirements on the element that handles the
announcement for legacy interoperation.</t> announcement for legacy interoperation.</t>
<t>As noted above, the element that inserts the sip.608 feature <t>As noted above, the element that inserts the sip.608 feature
capability is responsible for conveying the information referenced by capability is responsible for conveying the information referenced by
the Call-Info header field in the 608 response message. However, this the Call-Info header field in the 608 response message. However, this
specification does not mandate how to convey that information.</t> specification does not mandate how to convey that information.</t>
<t>Let us take the case where a telecommunications service provider <t>Let us take the case where a telecommunications service provider
controls the element inserting the sip.608 feature capability. It controls the element inserting the sip.608 feature capability. It
would be reasonable to expect the service provider would play an would be reasonable to expect the service provider would play an
announcement in the media path towards the UAC (caller). It is announcement in the media path towards the UAC (caller). It is
important to note the network element should be mindful of the media important to note the network element should be mindful of the media
type requested by the UAC as it formulates the announcement. For type requested by the UAC as it formulates the announcement. For
example, it would make sense for an INVITE that only indicated audio example, it would make sense for an INVITE that only indicated audio
codecs in the Session Description Protocol <xref codecs in the <xref format="default" target="RFC4566">Session
target="RFC4566">(SDP)</xref> to result in an audio announcement. Description Protocol (SDP)</xref> to result in an audio announcement.
Likewise, if the INVITE only indicated a <xref Likewise, if the INVITE only indicated <xref format="default"
target="RFC4103">real-time text codec</xref> and the network element target="RFC4103">real-time text</xref> and the network element can
can render the information in the requested media format, the network render the information in the requested media format, the network
element should send the information in a text format.</t> element should send the information in a text format.</t>
<t>It is also possible for the network element inserting the sip.608 <t>It is also possible for the network element inserting the sip.608
feature capability to be under the control of the same entity that feature capability to be under the control of the same entity that
controls the UAC. For example, a large call center might have legacy controls the UAC. For example, a large call center might have legacy
UACs, but have a modern outbound calling proxy that understands the UACs, but have a modern outbound calling proxy that understands the
full semantics of the 608 response code. In this case, it is enough full semantics of the 608 response code. In this case, it is enough
for the outbound calling proxy to digest the Call-Info information and for the outbound calling proxy to digest the Call-Info information and
handle the information digitally, rather than 'transcoding' the handle the information digitally rather than "transcoding" the
Call-Info information for presentation to the caller.</t> Call-Info information for presentation to the caller.</t>
</section> </section>
</section> </section>
<section anchor="EXAMPLES" title="Examples"> <section anchor="EXAMPLES" numbered="true" toc="default">
<name>Examples</name>
<t>These examples are not normative, do not include all protocol <t>These examples are not normative, do not include all protocol
elements, and may have errors. Review the protocol documents for actual elements, and may have errors. Review the protocol documents for actual
syntax and semantics of the protocol elements.</t> syntax and semantics of the protocol elements.</t>
<section title="Full Exchange"> <section numbered="true" toc="default">
<t>Given an INVITE, shamelessly taken from <xref target="SHAKEN"/>, <name>Full Exchange</name>
with the line breaks in the Identity header field for display purposes
only:</t>
<figure> <t>Given an INVITE, shamelessly taken from <xref format="default"
<artwork><![CDATA[ target="SHAKEN"/>, with the line breaks in the Identity header field
for display purposes only:</t>
<sourcecode name="" type=""><![CDATA[
INVITE sip:+12155550113@tel.one.example.net SIP/2.0 INVITE sip:+12155550113@tel.one.example.net SIP/2.0
Max-Forwards: 69 Max-Forwards: 69
Contact: <sip:+12155550112@[2001:db8::12]:50207;rinstance=9da3088f3> Contact: <sip:+12155550112@[2001:db8::12]:50207;rinstance=9da3088f3>
To: <sip:+12155550113@tel.one.example.net> To: <sip:+12155550113@tel.one.example.net>
From: "Alice" <sip:+12155550112@tel.two.example.net>;tag=614bdb40 From: "Alice" <sip:+12155550112@tel.two.example.net>;tag=614bdb40
Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI
P-Asserted-Identity: "Alice"<sip:+12155550112@tel.two.example.net>, P-Asserted-Identity: "Alice"<sip:+12155550112@tel.two.example.net>,
<tel:+12155550112> <tel:+12155550112>
CSeq: 2 INVITE CSeq: 2 INVITE
Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO, Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO,
MESSAGE, OPTIONS MESSAGE, OPTIONS
Content-Type: application/sdp Content-Type: application/sdp
Date: Tue, 16 Aug 2016 19:23:38 GMT Date: Tue, 16 Aug 2016 19:23:38 GMT
Feature-Caps: *;+sip.608 Feature-Caps: *;+sip.608
Identity: eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2V Identity: eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2V
uIiwieDV1IjoiaHR0cDovL2NlcnQuZXhhbXBsZTIubmV0L2V4YW1wbGUuY2VydCJ9.eyJ uIiwieDV1IjoiaHR0cDovL2NlcnQuZXhhbXBsZTIubmV0L2V4YW1wbGUuY2VydCJ9.eyJ
hdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6IisxMjE1NTU1MDExMyJ9LCJpYXQiOiIxNDcx hdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6IisxMjE1NTU1MDExMyJ9LCJpYXQiOiIxNDcx
Mzc1NDE4Iiwib3JpZyI6eyJ0biI6IisxMjE1NTU1MDExMiJ9LCJvcmlnaWQiOiIxMjNlN Mzc1NDE4Iiwib3JpZyI6eyJ0biI6IisxMjE1NTU1MDExMiJ9LCJvcmlnaWQiOiIxMjNlN
DU2Ny1lODliLTEyZDMtYTQ1Ni00MjY2NTU0NDAwMCJ9.QAht_eFqQlaoVrnEV56Qly-OU DU2Ny1lODliLTEyZDMtYTQ1Ni00MjY2NTU0NDAwMCJ9.QAht_eFqQlaoVrnEV56Qly-OU
tsDGifyCcpYjWcaR661Cz1hutFH2BzIlDswTahO7ujjqsWjeoOb4h97whTQJg;info= tsDGifyCcpYjWcaR661Cz1hutFH2BzIlDswTahO7ujjqsWjeoOb4h97whTQJg;info=
<http://cert.example2.net/example.cert>;alg=ES256 <http://cert.example2.net/example.cert>;alg=ES256
Content-Length: 153 Content-Length: 153
v=0 v=0
o=- 13103070023943130 1 IN IP6 2001:db8::177 o=- 13103070023943130 1 IN IP6 2001:db8::177
c=IN IP6 2001:db8::177 c=IN IP6 2001:db8::177
t=0 0 t=0 0
m=audio 54242 RTP/AVP 0 m=audio 54242 RTP/AVP 0
a=sendrecv a=sendrecv
]]></artwork> ]]></sourcecode>
</figure>
<t>An intermediary could reply:</t> <t>An intermediary could reply:</t>
<figure> <sourcecode name="" type=""><![CDATA[
<artwork><![CDATA[
SIP/2.0 608 Rejected SIP/2.0 608 Rejected
Via: SIP/2.0/UDP [2001:db8::177]:60012;branch=z9hG4bK-524287-1 Via: SIP/2.0/UDP [2001:db8::177]:60012;branch=z9hG4bK-524287-1
From: "Alice" <sip:+12155550112@tel.two.example.net>;tag=614bdb40 From: "Alice" <sip:+12155550112@tel.two.example.net>;tag=614bdb40
To: <sip:+12155550113@tel.one.example.net> To: <sip:+12155550113@tel.one.example.net>
Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI
CSeq: 2 INVITE CSeq: 2 INVITE
Call-Info: <https://block.example.net/complaint-jws>;purpose=jwscard Call-Info: <https://block.example.net/complaint-jws>;purpose=jwscard
]]></artwork> ]]></sourcecode>
</figure>
<t>The location https://block.example.net/complaint-jws resolves to a <t>The location https://block.example.net/complaint-jws resolves to a
JWS. One would construct the JWS as follows.</t> JWS. One would construct the JWS as follows.</t>
<t>The JWS header of this example jCard could be:</t> <t>The JWS header of this example jCard could be:</t>
<figure> <sourcecode name="" type="json">
<artwork><![CDATA[{ "alg":"ES256", { "alg":"ES256",
"typ":"vcard+json", "typ":"vcard+json",
"x5u":"https://certs.example.net/reject_key.cer" "x5u":"https://certs.example.net/reject_key.cer"
} }
</sourcecode>
]]></artwork>
</figure>
<t>Now, let us construct a minimal jCard. For this example, the jCard <t>Now, let us construct a minimal jCard. For this example, the jCard
refers the caller to an email address, refers the caller to an email address,
remediation@blocker.example.net:</t> remediation@blocker.example.net:</t>
<figure> <sourcecode name="" type="json">
<artwork><![CDATA[["vcard", ["vcard",
[ [
["version", {}, "text", "4.0"], ["version", {}, "text", "4.0"],
["fn", {}, "text", "Robocall Adjudication"], ["fn", {}, "text", "Robocall Adjudication"],
["email", {"type":"work"}, ["email", {"type":"work"}, "text",
"text", "remediation@blocker.example.net"] "remediation@blocker.example.net"]
] ]
] ]
</sourcecode>
]]></artwork>
</figure>
<t>With this jCard, we can now construct the JWT:</t> <t>With this jCard, we can now construct the JWT:</t>
<figure> <sourcecode name="" type="json">{
<artwork><![CDATA[{
"iat":1546008698, "iat":1546008698,
"jcard":["vcard", "jcard":["vcard",
[ [
["version", {}, "text", "4.0"], ["version", {}, "text", "4.0"],
["fn", {}, "text", "Robocall Adjudication"], ["fn", {}, "text", "Robocall Adjudication"],
["email", {"type":"work"}, ["email", {"type":"work"},
"text", "remediation@blocker.example.net"] "text", "remediation@blocker.example.net"]
] ]
] ]
} } </sourcecode>
]]></artwork>
</figure>
<t>To calculate the signature, we need to encode the JSON Object <t>To calculate the signature, we need to encode the JSON Object
Signing and Encryption (JOSE) header and JWT into base64url. As an Signing and Encryption (JOSE) header and JWT into base64url. As an
implementation note, one can trim whitespace in the JSON objects to implementation note, one can trim whitespace in the JSON objects to
save a few bytes. UACs MUST be prepared to receive pretty-printed, save a few bytes. UACs <bcp14>MUST</bcp14> be prepared to receive
compact, or bizarrely formatted JSON. For the purposes of this pretty-printed, compact, or bizarrely formatted JSON. For the purposes
example, we leave the objects with pretty whitespace. Speaking of of this example, we leave the objects with pretty whitespace. Speaking
pretty vs. machine formatting, these examples have line breaks in the of pretty vs. machine formatting, these examples have line breaks in
base64url encodings for ease of publication in the RFC format. The the base64url encodings for ease of publication in the RFC format. The
specification of base64url allows for these line breaks and the specification of base64url allows for these line breaks, and the
decoded text works just fine. However, those extra line break octets decoded text works just fine. However, those extra line-break octets
would affect the calculation of the signature. Implementations MUST would affect the calculation of the signature. Implementations
NOT insert line breaks into the base64url encodings of the JOSE header <bcp14>MUST NOT</bcp14> insert line breaks into the base64url
or JWT. This also means UACs MUST be prepared to receive arbitrarily encodings of the JOSE header or JWT. This also means UACs
long octet streams from the URI referenced by the Call-Info SIP <bcp14>MUST</bcp14> be prepared to receive arbitrarily long octet
header.</t> streams from the URI referenced by the Call-Info header field.</t>
<figure> <t>base64url of JOSE header:</t>
<artwork><![CDATA[base64url of JOSE header:
<artwork align="left" alt="" name="" type="hex-dump"><![CDATA[
eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJkK2pzb24iLCJ4NXUiOiJodHRwczov eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJkK2pzb24iLCJ4NXUiOiJodHRwczov
L2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0= L2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0=
]]></artwork>
base64url of JWT: <t>base64url of JWT:</t>
<artwork align="left" alt="" name="" type="hex-dump"><![CDATA[
eyJpYXQiOjE1NDYwMDg2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2ZXJzaW9uIix7 eyJpYXQiOjE1NDYwMDg2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2ZXJzaW9uIix7
fSwidGV4dCIsIjQuMCJdLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2NhbGwgQWRqdWRp fSwidGV4dCIsIjQuMCJdLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2NhbGwgQWRqdWRp
Y2F0aW9uIl0sWyJlbWFpbCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0IiwicmVtZWRp Y2F0aW9uIl0sWyJlbWFpbCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0IiwicmVtZWRp
YXRpb25AYmxvY2tlci5leGFtcGxlLm5ldCJdXV19 YXRpb25AYmxvY2tlci5leGFtcGxlLm5ldCJdXV19
]]></artwork> ]]></artwork>
</figure>
<t>In this case, the object to sign (remembering this is just a <t>In this case, the object to sign (remembering this is just a single
single, long line; the line breaks are for ease of review but do not long line; the line breaks are for ease of review but do not appear in
appear in the actual object) is as follows:</t> the actual object) is as follows:</t>
<figure> <artwork align="left" alt="" name="" type="hex-dump"><![CDATA[
<artwork><![CDATA[eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJk eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJk
K2pzb24iLCJ4NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9r K2pzb24iLCJ4NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9r
ZXkuY2VyIn0.eyJpYXQiOjE1NDYwMDg2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2 ZXkuY2VyIn0.eyJpYXQiOjE1NDYwMDg2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2
ZXJzaW9uIix7fSwidGV4dCIsIjQuMCJdLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2Nh ZXJzaW9uIix7fSwidGV4dCIsIjQuMCJdLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2Nh
bGwgQWRqdWRpY2F0aW9uIl0sWyJlbWFpbCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0 bGwgQWRqdWRpY2F0aW9uIl0sWyJlbWFpbCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0
IiwicmVtZWRpYXRpb25AYmxvY2tlci5leGFtcGxlLm5ldCJdXV19 IiwicmVtZWRpYXRpb25AYmxvY2tlci5leGFtcGxlLm5ldCJdXV19
]]></artwork> ]]></artwork>
</figure>
<t>We use the following X.509 PKCS #8-encoded ECDSA key, also <t>We use the following X.509 PKCS #8-encoded Elliptic Curve Digital
shamelessly taken from <xref target="SHAKEN"/>), as an example key for Signature Algorithm (ECDSA) key, also shamelessly taken from <xref
signing the hash of the above text. Do NOT use this key in real life! format="default" target="SHAKEN"/>, as an example key for signing the
It is for example purposes only. At the very least, we would strongly hash of the above text. Do NOT use this key in real life! It is for
recommend encrypting the key at rest.</t> example purposes only. At the very least, we would strongly recommend
encrypting the key at rest.</t>
<figure> <artwork align="left" alt="" name="" type=""><![CDATA[
<artwork><![CDATA[-----BEGIN PRIVATE KEY----- -----BEGIN PRIVATE KEY-----
MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgi7q2TZvN9VDFg8Vy MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgi7q2TZvN9VDFg8Vy
qCP06bETrR2v8MRvr89rn4i+UAahRANCAAQWfaj1HUETpoNCrOtp9KA8o0V79IuW qCP06bETrR2v8MRvr89rn4i+UAahRANCAAQWfaj1HUETpoNCrOtp9KA8o0V79IuW
ARKt9C1cFPkyd3FBP4SeiNZxQhDrD0tdBHls3/wFe8++K2FrPyQF9vuh ARKt9C1cFPkyd3FBP4SeiNZxQhDrD0tdBHls3/wFe8++K2FrPyQF9vuh
-----END PRIVATE KEY----- -----END PRIVATE KEY-----
-----BEGIN PUBLIC KEY----- -----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8HNbQd/TmvCKwPKHkMF9fScavGeH MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8HNbQd/TmvCKwPKHkMF9fScavGeH
78YTU8qLS8I5HLHSSmlATLcslQMhNC/OhlWBYC626nIlo7XeebYS7Sb37g== 78YTU8qLS8I5HLHSSmlATLcslQMhNC/OhlWBYC626nIlo7XeebYS7Sb37g==
-----END PUBLIC KEY----- -----END PUBLIC KEY-----
]]></artwork> ]]></artwork>
</figure>
<t>The resulting JWS, using the above key on the above object, renders <t>The resulting JWS, using the above key on the above object, renders
the following ECDSA P-256 SHA-256 digital signature.</t> the following ECDSA P-256 SHA-256 digital signature.</t>
<figure> <artwork align="left" alt="" name="hex-dump" type=""><![CDATA[
<artwork><![CDATA[7uz2SADRvPFOQOO_UgF2ZTUjPlDTegtPrYB04UHBMwBD6g9AmL 7uz2SADRvPFOQOO_UgF2ZTUjPlDTegtPrYB04UHBMwBD6g9AmL
5harLJdTKDSTtH-LOV1jwJaGRUOUJiwP27ag 5harLJdTKDSTtH-LOV1jwJaGRUOUJiwP27ag
]]></artwork> ]]></artwork>
</figure>
<t>Thus, the JWS stored at https://blocker.example.net/complaints-jws, <t>Thus, the JWS stored at https://blocker.example.net/complaints-jws
would contain:</t> would contain:</t>
<figure> <artwork align="left" alt="" name="hex-dump" type=""><![CDATA[
<artwork><![CDATA[
eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJkK2pzb24iLCJ4NXUiOiJodHRwczovL eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJkK2pzb24iLCJ4NXUiOiJodHRwczovL
2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0.eyJpYXQiOjE1NDYwMD 2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0.eyJpYXQiOjE1NDYwMD
g2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2ZXJzaW9uIix7fSwidGV4dCIsIjQuMCJ g2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2ZXJzaW9uIix7fSwidGV4dCIsIjQuMCJ
dLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2NhbGwgQWRqdWRpY2F0aW9uIl0sWyJlbWFp dLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2NhbGwgQWRqdWRpY2F0aW9uIl0sWyJlbWFp
bCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0IiwicmVtZWRpYXRpb25AYmxvY2tlci5le bCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0IiwicmVtZWRpYXRpb25AYmxvY2tlci5le
GFtcGxlLm5ldCJdXV19.7uz2SADRvPFOQOO_UgF2ZTUjPlDTegtPrYB04UHBMwBD6 GFtcGxlLm5ldCJdXV19.7uz2SADRvPFOQOO_UgF2ZTUjPlDTegtPrYB04UHBMwBD6
g9AmL5harLJdTKDSTtH-LOV1jwJaGRUOUJiwP27ag g9AmL5harLJdTKDSTtH-LOV1jwJaGRUOUJiwP27ag
]]></artwork> ]]></artwork>
</figure>
</section> </section>
<section title="Web Site jCard"> <section numbered="true" toc="default">
<name>Web Site jCard</name>
<t>For an intermediary that provides a Web site for adjudication, the <t>For an intermediary that provides a Web site for adjudication, the
jCard could contain the following. Note we do not show the calculation jCard could contain the following. Note that we do not show the
of the JWS; the URI reference in the Call-Info header field would be calculation of the JWS; the URI reference in the Call-Info header
to the JWS of the signed jCard.</t> field would be to the JWS of the signed jCard.</t>
<figure> <sourcecode name="" type="json">
<artwork><![CDATA[["vcard", ["vcard",
[ [
["version", {}, "text", "4.0"], ["version", {}, "text", "4.0"],
["fn", {}, "text", "Robocall Adjudication"], ["fn", {}, "text", "Robocall Adjudication"],
["url", {"type":"work"}, ["url", {"type":"work"},
"text", "https://blocker.example.net/adjudication-form"] "text", "https://blocker.example.net/adjudication-form"]
] ]
] ]]></artwork> ] </sourcecode>
</figure>
</section> </section>
<section title="Multi-modal jCard"> <section numbered="true" toc="default">
<name>Multi-modal jCard</name>
<t>For an intermediary that provides a telephone number and a postal <t>For an intermediary that provides a telephone number and a postal
address, the jCard could contain the following. Note we do not show address, the jCard could contain the following. Note that we do not
the calculation of the JWS; the URI reference in the Call-Info header show the calculation of the JWS; the URI reference in the Call-Info
field would be to the JWS of the signed jCard.</t> header field would be to the JWS of the signed jCard.</t>
<figure> <sourcecode name="" type="json">["vcard",
<artwork><![CDATA[["vcard",
[ [
["version", {}, "text", "4.0"], ["version", {}, "text", "4.0"],
["fn", {}, "text", "Robocall Adjudication"], ["fn", {}, "text", "Robocall Adjudication"],
["adr", {"type":"work"}, "text", ["adr", {"type":"work"}, "text",
["Argument Clinic", ["Argument Clinic",
"12 Main St","Anytown","AP","000000","Somecountry"] "12 Main St","Anytown","AP","000000","Somecountry"]
] ]
["tel", {"type":"work"}, "uri", "tel:+1-555-555-0112"] ["tel", {"type":"work"}, "uri", "tel:+1-555-555-0112"]
] ]
] ]]></artwork> ]</sourcecode>
</figure>
<t>Note that it is up to the UAC to decide which jCard contact <t>Note that it is up to the UAC to decide which jCard contact
modality, if any, it will use.</t> modality, if any, it will use.</t>
</section> </section>
<section title="Legacy Interoperability"> <section numbered="true" toc="default">
<t><xref target="legacy_ladder"/> depicts a call flow illustrating <name>Legacy Interoperability</name>
legacy interoperability. In this non-normative example, we see a UAC
that does not support the full semantics for 608. However, there is an
SBC that does support 608. Per <xref target="RFC6809"/>, the SBC can
insert "*;+sip.608" into the Feature-Caps header field for the INVITE.
When the intermediary, labeled "Called Party Proxy" in the figure,
rejects the call, it knows it can simply perform the processing
described in this document. Since the intermediary saw the sip.608
feature capability, it knows it does not need to send any media
describing whom to contact in the event of an erroneous rejection. For
illustrative purposes, the figure shows generic SIP Proxies in the
flow. Their presence or absence or the number of proxies is not
relevant to the operation of the protocol. They are in the figure to
show that proxies that do not understand the sip.608 feature
capability can still participate in a network offering 608
services.</t>
<figure anchor="legacy_ladder" title="Legacy Operation"> <t><xref format="default" target="legacy_ladder"/> depicts a call flow
<artwork><![CDATA[ illustrating legacy interoperability. In this non-normative example,
+---------+ we see a UAC that does not support the full semantics for 608.
| Call | However, there is an SBC that does support 608. Per <xref
|Analytics| format="default" target="RFC6809"/>, the SBC can insert "*;+sip.608"
| Engine | into the Feature-Caps header field for the INVITE. When the
+--+--+---+ intermediary, labeled "Called Party Proxy" in the figure, rejects the
^ | call, it knows it can simply perform the processing described in this
| | document. Since the intermediary saw the sip.608 feature capability,
| v it knows it does not need to send any media describing whom to contact
+-+--+-+ in the event of an erroneous rejection. For illustrative purposes, the
+---+ +-----+ +---+ +-----+ +-----+ |Called| figure shows generic SIP Proxies in the flow. Their presence or
|UAC+----+Proxy+----+SBC+----+Proxy+----+Proxy+----+Party | absence or the number of proxies is not relevant to the operation of
+---+ +-----+ +---+ +-----+ +-----+ |Proxy | the protocol. They are in the figure to show that proxies that do not
| | +------+ understand the sip.608 feature capability can still participate in a
| INVITE | | network offering 608 services.</t>
|------------------>| |
| | INVITE | <figure anchor="legacy_ladder">
| |------------------------------>| <name>Legacy Operation</name>
| | Feature-Caps: *;+sip.608 |
| | |
| | 608 Rejected |
| |<------------------------------|
| 183 | Call-Info: <...> |
|<------------------| [path for Call-Info elided |
| SDP for media | for illustration purposes]|
| | |
| PRACK | |
|------------------>| |
| | |
| 200 OK PRACK | |
|<------------------| |
| | |
|<== Announcement ==| |
| | |
| 608 Rejected | |
|<------------------| |
| Call-Info: <...> | |
| | |
<artwork align="center" alt="" name="" type="ascii-art"><![CDATA[
+---------+
| Call |
|Analytics|
| Engine |
+--+--+---+
^ |
| |
| v
+-+--+-+
+---+ +-----+ +---+ +-----+ +-----+ |Called|
|UAC+----+Proxy+----+SBC+----+Proxy+----+Proxy+----+Party |
+---+ +-----+ +---+ +-----+ +-----+ |Proxy |
| | +------+
| INVITE | |
|------------------>| |
| | INVITE |
| |------------------------------>|
| | Feature-Caps: *;+sip.608 |
| | |
| | 608 Rejected |
| |<------------------------------|
| 183 | Call-Info: <...> |
|<------------------| [path for Call-Info elided |
| SDP for media | for illustration purposes]|
| | |
| PRACK | |
|------------------>| |
| | |
| 200 OK PRACK | |
|<------------------| |
| | |
|<== Announcement ==| |
| | |
| 608 Rejected | |
|<------------------| |
| Call-Info: <...> | |
| | |
]]></artwork> ]]></artwork>
</figure> </figure>
<t>When the SBC receives the 608 response code, it correlates that <t>When the SBC receives the 608 response code, it correlates that
with the original INVITE from the UAC. The SBC remembers that it with the original INVITE from the UAC. The SBC remembers that it
inserted the sip.608 feature capability, which means it is responsible inserted the sip.608 feature capability, which means it is responsible
for somehow alerting the UAC the call failed and whom to contact. At for somehow alerting the UAC the call failed and disclosing whom to
this point the SBC can play a prompt, either natively or through a contact. At this point, the SBC can play a prompt, either natively or
mechanism such as <xref target="RFC4240">NETANN</xref>, that sends the through a mechanism such as <xref format="default"
relevant information in the appropriate media to the UAC. Since this target="RFC4240">NETANN</xref>, that sends the relevant information in
is a potentially long transaction and there is a chance the UAC is the appropriate media to the UAC. Since this is a potentially long
using an unreliable transport protocol, the UAC will have indicated transaction and there is a chance the UAC is using an unreliable
support for provisional responses, the SBC will indicate it requires a transport protocol, the UAC will have indicated support for
PRACK from the UAC in the 183 response, the UAC will provide the provisional responses, the SBC will indicate it requires a PRACK from
PRACK, and the SBC will acknowledge receipt of the PRACK before the UAC in the 183 response, the UAC will provide the PRACK, and the
playing the announcement.</t> SBC will acknowledge receipt of the PRACK before playing the
announcement.</t>
<t>As an example, the SBC could extract the FN and TEL jCard fields <t>As an example, the SBC could extract the FN and TEL jCard fields
and play something like a special information tone (see Telcordia and play something like a special information tone (see Section
<xref target="SR-2275">SR-2275</xref> section 6.21.2.1 or <xref 6.21.2.1 of Telcordia <xref format="default"
target="ITU.E.180.1998">ITU-T E.180</xref> section 7), followed by target="SR-2275">SR-2275</xref> or Section 7 of <xref format="default"
"Your call has been rejected by ...", followed by a text-to-speech target="ITU.E.180.1998">ITU-T E.180</xref>), followed by "Your call
translation of the FN text, followed by "You can reach them on", has been rejected by...", followed by a text-to-speech translation of
followed by a text-to-speech translation of the telephone number in the FN text, followed by "You can reach them on...", followed by a
the TEL field.</t> text-to-speech translation of the telephone number in the TEL
field.</t>
<t>Note the SBC also still sends the full 608 response code, including <t>Note that the SBC also still sends the full 608 response code,
the Call-Info header, towards the UAC.</t> including the Call-Info header field, towards the UAC.</t>
</section> </section>
</section> </section>
<section title="IANA Considerations"> <section numbered="true" toc="default">
<section title="SIP Response Code"> <name>IANA Considerations</name>
<t>This document defines a new SIP response code, 608 in the "Response
Codes" subregistry of the "Session Initiation Protocol (SIP)
Parameters" registry defined in <xref target="RFC3261"/>.<list
style="hanging">
<t hangText="Response code:">608</t>
<t hangText="Description:">Rejected</t> <section numbered="true" toc="default">
<name>SIP Response Code</name>
<t hangText="Reference:">[RFCXXXX]</t> <t>This document defines a new SIP response code, 608, in the
</list></t> "Response Codes" subregistry of the "Session Initiation Protocol (SIP)
Parameters" registry defined in <xref format="default"
target="RFC3261"/>.</t>
<dl indent="18" newline="false" spacing="compact">
<dt>Response code:</dt>
<dd>608</dd>
<dt>Description:</dt>
<dd>Rejected</dd>
<dt>Reference:</dt>
<dd>RFC 8688</dd>
</dl>
</section> </section>
<section title="SIP Feature-Capability Indicator"> <section numbered="true" toc="default">
<t>This document defines the feature capability sip.608 in the "SIP <name>SIP Feature-Capability Indicator</name>
<t>This document defines the feature capability, sip.608, in the "SIP
Feature-Capability Indicator Registration Tree" registry defined in Feature-Capability Indicator Registration Tree" registry defined in
<xref target="RFC6809"/>.<list style="hanging"> <xref format="default" target="RFC6809"/>.</t>
<t hangText="Name:">sip.608</t>
<t hangText="Description:">This feature capability indicator, when <dl indent="14" newline="false" spacing="compact">
included in a Feature-Caps header field of an INVITE request, <dt>Name:</dt>
indicates that the entity associated with the indicator will be
responsible for indicating to the caller any information contained
in the 608 SIP response code, specifically the value referenced by
the Call-Info header.</t>
<t hangText="Reference:">[RFCXXXX]</t> <dd>sip.608</dd>
</list></t>
<dt>Description:</dt>
<dd>This feature-capability indicator, when included in a
Feature-Caps header field of an INVITE request, indicates that the
entity associated with the indicator will be responsible for
indicating to the caller any information contained in the 608 SIP
response code, specifically, the value referenced by the Call-Info
header field.</dd>
<dt>Reference:</dt>
<dd>RFC 8688</dd>
</dl>
</section> </section>
<section anchor="JWT-IANA" title="JSON Web Token Claim"> <section anchor="JWT-IANA" numbered="true" toc="default">
<name>JSON Web Token Claim</name>
<t>This document defines the new JSON Web Token claim in the "JSON Web <t>This document defines the new JSON Web Token claim in the "JSON Web
Token Claims" sub-registry created by <xref target="RFC7519"/>. <xref Token Claims" subregistry created by <xref format="default"
target="JWT"/> defines the syntax. The required information is:<list target="RFC7519"/>. <xref format="default" target="JWT"/> defines the
style="hanging"> syntax. The required information is:</t>
<t hangText="Claim Name:">jcard</t>
<t hangText="Claim Description:">jCard data</t> <dl indent="20" newline="false" spacing="compact">
<dt>Claim Name:</dt>
<t hangText="Change Controller:">IESG</t> <dd>jcard</dd>
<t hangText="Reference:">[RFCXXXX], <xref target="RFC7095"/></t> <dt>Claim Description:</dt>
</list></t>
<dd>jCard data</dd>
<dt>Change Controller:</dt>
<dd>IESG</dd>
<dt>Reference:</dt>
<dd>RFC 8688, <xref format="default" target="RFC7095"/></dd>
</dl>
</section> </section>
<section title="Call-Info Purpose"> <section numbered="true" toc="default">
<name>Call-Info Purpose</name>
<t>This document defines the new predefined value "jwscard" for the <t>This document defines the new predefined value "jwscard" for the
"purpose" header field parameter of the Call-Info header field. This "purpose" header field parameter of the Call-Info header field. This
modifies the "Header Field Parameters and Parameter Values" modifies the "Header Field Parameters and Parameter Values"
subregistry of the "Session Initiation Protocol (SIP) Parameters" subregistry of the "Session Initiation Protocol (SIP) Parameters"
registry by adding this RFC as a reference to the line for the header registry by adding this RFC as a reference to the line for the header
field "Call-Info" and parameter name "purpose":<list style="hanging"> field "Call-Info" and parameter name "purpose":</t>
<t hangText="Header Field:">Call-Info</t>
<t hangText="Parameter Name:">purpose</t> <dl indent="20" newline="false" spacing="compact">
<dt>Header Field:</dt>
<t hangText="Predefined Values:">Yes</t> <dd>Call-Info</dd>
<t hangText="Reference:">[RFCXXXX]</t> <dt>Parameter Name:</dt>
</list></t>
<dd>purpose</dd>
<dt>Predefined Values:</dt>
<dd>Yes</dd>
<dt>Reference:</dt>
<dd>RFC 8688</dd>
</dl>
</section> </section>
</section> </section>
<section anchor="Security" title="Security Considerations"> <section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>Intermediary operators need to be mindful to whom they are sending <t>Intermediary operators need to be mindful to whom they are sending
the 608 response. The intermediary could be rejecting a truly malicious the 608 response. The intermediary could be rejecting a truly malicious
caller. This raises two issues. The first is the caller, now alerted an caller. This raises two issues. The first is the caller, now alerted
intermediary is automatically rejecting their call attempts, may change that an intermediary is automatically rejecting their call attempts, may
their call behavior to defeat call blocking systems. The second, and change their call behavior to defeat call-blocking systems. The second,
more significant risk, is that by providing a contact in the Call-Info and more significant risk, is that by providing a contact in the
header field, the intermediary may be giving the malicious caller a Call-Info header field, the intermediary may be giving the malicious
vector for attack. In other words, the intermediary will be publishing caller a vector for attack. In other words, the intermediary will be
an address that a malicious actor may use to launch an attack on the publishing an address that a malicious actor may use to launch an attack
intermediary. Because of this, intermediary operators may wish to on the intermediary. Because of this, intermediary operators may wish to
configure their response to only include a Call-Info header field for configure their response to only include a Call-Info header field for
INVITE or other signed initiating methods and that pass validation by INVITE, or other signed initiating methods, that pass validation by
<xref target="RFC8224">STIR</xref>.</t> <xref format="default" target="RFC8224">STIR</xref>.</t>
<t>Another risk is as follows. Consider an attacker that floods a proxy <t>Another risk is as follows. Consider an attacker that floods a proxy
that supports the sip.608 feature. However, the SDP in the INVITE that supports the sip.608 feature. However, the SDP in the INVITE
request refers to a victim device. Moreover, the attacker somehow knows request refers to a victim device. Moreover, the attacker somehow knows
there is a 608-aware gateway connecting to the victim who is on a there is a 608-aware gateway connecting to the victim who is on a
segment that lacks the sip.608 feature capability. Because the mechanism segment that lacks the sip.608 feature capability. Because the mechanism
described here can result in sending an audio file to the target of the described here can result in sending an audio file to the target of the
SDP, an attacker could use the mechanism described by this document as SDP, an attacker could use the mechanism described by this document as
an amplification attack, given a SIP INVITE can be under 1 kilobyte and an amplification attack, given a SIP INVITE can be under 1 kilobyte and
an audio file can be hundreds of kilobytes. One remediation for this is an audio file can be hundreds of kilobytes. One remediation for this is
for devices that insert a sip.608 feature capability to only transmit for devices that insert a sip.608 feature capability to only transmit
media to what is highly likely to be the actual source of the call media to what is highly likely to be the actual source of the call
attempt. A method for this is to only play media in response to a attempt. A method for this is to only play media in response to a
STIR-signed INVITE that passes validation. Beyond requiring a valid STIR STIR-signed INVITE that passes validation. Beyond requiring a valid STIR
signature on the INVITE, the intermediary can also use remediation signature on the INVITE, the intermediary can also use remediation
procedures such as doing the connectivity checks specified by <xref procedures such as doing the connectivity checks specified by <xref
target="RFC8445">Interactive Connectivity Establishment</xref>. If the format="default" target="RFC8445">Interactive Connectivity
target did not request the media, the check will fail.</t> Establishment</xref>. If the target did not request the media, the check
will fail.</t>
<t>Yet another risk is a malicious intermediary that generates a <t>Yet another risk is a malicious intermediary that generates a
malicious 608 response with a jCard referring to a malicious agent. For malicious 608 response with a jCard referring to a malicious agent. For
example, the recipient of a 608 may receive a TEL URI in the vCard. When example, the recipient of a 608 may receive a TEL URI in the vCard. When
the recipient calls that address, the malicious agent could ask for the recipient calls that address, the malicious agent could ask for
personally identifying information. However, instead of using that personally identifying information. However, instead of using that
information to verify the recipient's identity, they are phishing the information to verify the recipient's identity, they are phishing the
information for nefarious ends. A similar scenario can unfold if the information for nefarious ends. A similar scenario can unfold if the
malicious agent inserts a URI that points to a phishing or other site. malicious agent inserts a URI that points to a phishing or other site.
As such, we strongly recommend the recipient validates to whom they are As such, we strongly recommend the recipient validates to whom they are
communicating with if asking to adjudicate an erroneously rejected call communicating with if asking to adjudicate an erroneously rejected call
attempt. Since we may also be concerned about intermediate nodes attempt. Since we may also be concerned about intermediate nodes
modifying contact information, we can address both issues with a single modifying contact information, we can address both issues with a single
solution. The remediation is to require the intermediary to sign the solution. The remediation is to require the intermediary to sign the
jCard. Signing the jCard provides integrity protection. In addition, one jCard. Signing the jCard provides integrity protection. In addition, one
can imagine mechanisms such as used by <xref can imagine mechanisms such as used by <xref format="default"
target="SHAKEN">SHAKEN</xref>.</t> target="SHAKEN">SHAKEN</xref>.</t>
<t>Similarly, one can imagine an adverse agent that maliciously spoofs a <t>Similarly, one can imagine an adverse agent that maliciously spoofs a
608 response with a victim's contact address to many active callers, who 608 response with a victim's contact address to many active callers who
may then all send redress requests to the specified address (the basis may then all send redress requests to the specified address (the basis
for a denial-of-service attack). The process would occur as follows: (1) for a denial-of-service attack). The process would occur as follows: (1)
a malicious agent senses INVITE requests from a variety of UACs and (2) a malicious agent senses INVITE requests from a variety of UACs and (2)
spoofs 608 responses with an unsigned redress address before the spoofs 608 responses with an unsigned redress address before the
intended receivers can respond, causing (3) the UACs to all contact the intended receivers can respond, causing (3) the UACs to all contact the
redress address at once. The jCard encoding allows the UAC to verify the redress address at once. The jCard encoding allows the UAC to verify the
blocking intermediary's identity before contacting the redress address. blocking intermediary's identity before contacting the redress address.
Specifically, because the sender signs the jCard, we can Specifically, because the sender signs the jCard, we can
cryptographically trace the sender of the jCard. Given the protocol cryptographically trace the sender of the jCard. Given the protocol
machinery of having a signature, one can apply local policy to decide machinery of having a signature, one can apply local policy to decide
whether to believe the sender of the jCard represents the owner of the whether to believe that the sender of the jCard represents the owner of
contact information found in the jCard. This guards against a malicious the contact information found in the jCard. This guards against a
agent spoofing 608 responses.</t> malicious agent spoofing 608 responses.</t>
<t>Specifically, one could use policies around signing certificate <t>Specifically, one could use policies around signing certificate
issuance as a mechanism for traceback to the entity issuing the jCard. issuance as a mechanism for traceback to the entity issuing the jCard.
One check could be verifying the identity of the subject of the One check could be verifying that the identity of the subject of the
certificate relates to the To header field of the initial SIP request, certificate relates to the To header field of the initial SIP request,
similar to validating the intermediary was vouching for the From header similar to validating that the intermediary was vouching for the From
field of a SIP request with that identity. Note that we are only header field of a SIP request with that identity. Note that we are only
protecting against a malicious intermediary and not a hidden protecting against a malicious intermediary and not a hidden
intermediary attack (formerly known as a "man in the middle attack"). intermediary attack (formerly known as a "man-in-the-middle attack").
Thus, we only need to ensure the signature is fresh, which is why we Thus, we only need to ensure the signature is fresh, which is why we
include "iat". For most implementations, we assume that the intermediary include "iat". For most implementations, we assume that the intermediary
has a single set of contact points and will generate the jCard on has a single set of contact points and will generate the jCard on
demand. As such, there is no need to directly correlate HTTPS fetches to demand. As such, there is no need to directly correlate HTTPS fetches to
specific calls. However, since the intermediary is in control of the specific calls. However, since the intermediary is in control of the
jCard and Call-Info response, an intermediary may choose to encode jCard and Call-Info response, an intermediary may choose to encode
per-call information in the URI returned in a given 608 response. per-call information in the URI returned in a given 608 response.
However, if the intermediary does go that route, the intermediary MUST However, if the intermediary does go that route, the intermediary
use a non-deterministic URI reference mechanism and be prepared to <bcp14>MUST</bcp14> use a non-deterministic URI reference mechanism and
return dummy responses to URI requests referencing calls that do not be prepared to return dummy responses to URI requests referencing calls
exist so that attackers attempting to glean call metadata by guessing that do not exist so that attackers attempting to glean call metadata by
URI's (and thus calls) will not get any actionable information from the guessing URIs (and thus calls) will not get any actionable information
HTTPS GET.</t> from the HTTPS GET.</t>
<t>Since the decision of whether to include Call-Info in the 608 <t>Since the decision of whether to include Call-Info in the 608
response is a matter of policy, one thing to consider is whether a response is a matter of policy, one thing to consider is whether a
legitimate caller can ascertain whom to contact without including such legitimate caller can ascertain whom to contact without including such
information in the 608. For example, in some jurisdictions, if only the information in the 608. For example, in some jurisdictions, if only the
terminating service provider can be the intermediary, the caller can terminating service provider can be the intermediary, the caller can
look up who the terminating service provider is based on the routing look up who the terminating service provider is based on the routing
information for the dialed number. Thus, the Call-Info jCard could be information for the dialed number. Thus, the Call-Info jCard could be
redundant information. However, the factors going into a particular redundant information. However, the factors going into a particular
service provider's or jurisdiction's choice of whether to include service provider's or jurisdiction's choice of whether to include
Call-Info is outside the scope of this document.</t> Call-Info is outside the scope of this document.</t>
</section> </section>
</middle>
<section anchor="Acknowledgements" title="Acknowledgements"> <back>
<t>This document liberally lifts from <xref target="RFC8197"/> in its <references>
text and structure. However, the mechanism and purpose of 608 is quite <name>References</name>
different than 607. Any errors are the current editor's and not the
editor of RFC8197. Thanks also go to Ken Carlberg of the FCC, Russ
Housley, Paul Kyzivat, and Tolga Asveren for their suggestions on
improving the draft. Tolga's suggestion to provide a mechanism for
legacy interoperability served to expand the draft by 50%. In addition,
Tolga came up with the jCard attack. Finally, Christer Holmberg as
always provided a close reading and fixed a SIP feature capability bug
found by Yehoshua Gev.</t>
<t>Of course, we appreciated the close read and five pages of comments
from our estimable Area Director, Adam Roach. In addition, we received
valuable comments during IETF Last Call and JWT review from Ines Robles,
Mike Jones, and Brian Campbell and IESG review from Alissa Cooper,
&Eacute;ric Vyncke, Alexey Melnikov, Benjamin Kaduk, Barry Leiba, and
with most glee, Warren Kumari.</t>
<t>Finally, Bhavik Nagda provided clarifying edits as well and more <references>
especially wrote and tested an implementation of the 608 response code <name>Normative References</name>
in Kamailio. Code is available at <eref
target="https://github.com/nagdab/608_Implementation"/>. Grace Chuan
from MIT regenerated and verified the JWT while working at the FCC.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** --> <xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
2119.xml"/>
<back> <xi:include
<references title="Normative References"> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
&RFC2119; 3261.xml"/>
&RFC3261; <xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
3262.xml"/>
&RFC3262; <xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
3326.xml"/>
&RFC3326; <xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
6809.xml"/>
&RFC6809; <xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
7095.xml"/>
&RFC7095; <xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
7515.xml"/>
&RFC7515; <xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
7518.xml"/>
&RFC7518; <xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
7519.xml"/>
&RFC7519; <xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
8174.xml"/>
</references>
&RFC8174; <references>
</references> <name>Informative References</name>
<references title="Informative References"> <xi:include
&RFC4103; href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
4103.xml"/>
&RFC4240; <xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
4240.xml"/>
&RFC4566; <xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
4566.xml"/>
&RFC5039; <xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
5039.xml"/>
&RFC6350; <xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
6350.xml"/>
&RFC7092; <xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
7092.xml"/>
&RFC7340; <xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
7340.xml"/>
&RFC8197; <xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
8197.xml"/>
&RFC8224; <xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
8224.xml"/>
&RFC8259; <xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
8259.xml"/>
&RFC8445; <xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
8445.xml"/>
<!-- [rfced] [SHAKEN] This URL is correct --> <reference anchor="SHAKEN"
target="https://www.sipforum.org/download/sip-forum-twg-10-si
gnature-based-handling-of-asserted-information-using-tokens-shaken-pdf/?wpdmdl=2
813">
<front>
<title>Signature-based Handling of Asserted information using
toKENs (SHAKEN)</title>
<reference anchor="SHAKEN" <seriesInfo name="ATIS" value="1000074"/>
target="https://www.sipforum.org/download/sip-forum-twg-10-sign
ature-based-handling-of-asserted-information-using-tokens-shaken-pdf/?wpdmdl=281
3">
<front>
<title>Signature-based Handling of Asserted information using toKENs
(SHAKEN)</title>
<author> <author>
<organization>Alliance for Telecommunications Industry Solutions <organization>ATIS/SIP Forum IP-INNI Task Group</organization>
(ATIS) and the SIP Forum</organization> </author>
</author>
<date day="5" month="1" year="2017"/> <date month="January" year="2017"/>
</front> </front>
</reference>
<seriesInfo name="ATIS" value="1000074"/> <reference anchor="BaseRate"
</reference> target="https://apps.dtic.mil/docs/citations/ADA045772">
<front>
<title>The Base-Rate Fallacy in Probability Judgements</title>
<!-- [rfced] [BaseRate] This URL is correct --> <author fullname="Maya Bar-Hillel" initials="M."
surname="Bar-Hillel">
<organization>Hebrew University</organization>
</author>
<reference anchor="BaseRate" <date month="April" year="1977"/>
target=" https://apps.dtic.mil/docs/citations/ADA045772"> </front>
<front> </reference>
<title>The Base-Rate Fallacy in Probability Judgements</title>
<author fullname="Maya Bar-Hillel" initials="M." <reference anchor="ITU.E.180.1998">
surname="Bar-Hillel"> <front>
<organization>Hebrew University</organization> <title>Technical characteristics of tones for the telephone
</author> service</title>
<date month="4" year="1977"/> <seriesInfo name="ITU-T Recommendation" value="E.180/Q.35"/>
</front>
</reference>
<!-- [rfced] [ITU.E.180.1998] URL: https://www.google.com/url?sa=t&rct=j&q=&esrc <author>
=s&source=web&cd=1&ved=2ahUKEwiJxOvUh-3jAhVCIjQIHXg1CdIQFjAAegQIARAC&url=https%3 <organization>ITU-T</organization>
A%2F%2Fwww.itu.int%2Frec%2Fdologin_pub.asp%3Flang%3De%26id%3DT-REC-E.180-199803- </author>
I!!PDF-E%26type%3Ditems&usg=AOvVaw3P1BYFbmmEKIXIcpA1ifj6 -->
<reference anchor="ITU.E.180.1998"> <date month="March" year="1998"/>
<front> </front>
<title>Technical characteristics of tones for the telephone </reference>
service</title>
<author> <reference anchor="SR-2275">
<organization>International Telecommunications <front>
Union</organization> <title>Telcordia Notes on the Networks</title>
</author>
<date month="March" year="1998"/> <seriesInfo name="Telcordia" value="SR-2275"/>
</front>
<seriesInfo name="ITU" value="Recommendation E.180/Q.35"/> <author>
</reference> <organization>Telcordia</organization>
</author>
<!-- [rfced] [SR-2275] Found this URL but it is dated 1997 http://www.wedophones <date month="October" year="2000"/>
.com/Manuals/BellCore/BellCore%20Notes%20On%20The%20Network.PDF --> </front>
</reference>
</references>
</references>
<reference anchor="SR-2275"> <section anchor="Acknowledgements" numbered="false" toc="default">
<front> <name>Acknowledgements</name>
<title>Bellcore Notes on the Networks</title>
<author> <t>This document liberally lifts from <xref format="default"
<organization>Telcordia</organization> target="RFC8197"/> in its text and structure. However, the mechanism and
</author> purpose of 608 is quite different than 607. Any errors are the current
editor's and not the editor of RFC 8197. Thanks also go to Ken Carlberg
of the FCC, Russ Housley, Paul Kyzivat, and Tolga Asveren for their
suggestions on improving the document. Tolga's suggestion to provide a
mechanism for legacy interoperability served to expand the document by
50%. In addition, Tolga came up with the jCard attack. Finally, Christer
Holmberg, as always, provided a close reading and fixed a SIP
feature-capability bug found by Yehoshua Gev.</t>
<date month="October" year="2000"/> <t>Of course, we appreciated the close read and five pages of comments
</front> from our estimable Area Director, Adam Roach. In addition, we received
valuable comments during IETF Last Call and JWT review from Ines Robles,
Mike Jones, and Brian Campbell, and IESG review from Alissa Cooper, Eric
Vyncke, Alexey Melnikov, Benjamin Kaduk, Barry Leiba, and with most
glee, Warren Kumari.</t>
<seriesInfo name="Telcordia" value="SR-2275"/> <t>Finally, Bhavik Nagda provided clarifying edits as well and, more
</reference> especially, wrote and tested an implementation of the 608 response code
</references> in Kamailio. Code is available at <eref
target="https://github.com/nagdab/608_Implementation"/>. Grace Chuan
from MIT regenerated and verified the JWT while working at the FCC.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 179 change blocks. 
685 lines changed or deleted 743 lines changed or added

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