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