draft-ietf-sipcore-rejected-08.txt   draft-ietf-sipcore-rejected-09.txt 
SIPCORE E. Burger SIPCORE E. Burger
Internet-Draft Georgetown University Internet-Draft Georgetown University
Intended status: Standards Track B. Nagda Intended status: Standards Track B. Nagda
Expires: November 22, 2019 Massachusetts Institute of Technology Expires: December 30, 2019 Massachusetts Institute of Technology
May 21, 2019 June 28, 2019
A Session Initiation Protocol (SIP) Response Code for Rejected Calls A Session Initiation Protocol (SIP) Response Code for Rejected Calls
draft-ietf-sipcore-rejected-08 draft-ietf-sipcore-rejected-09
Abstract Abstract
This document defines the 608 (Rejected) SIP response code. This This document defines the 608 (Rejected) SIP response code. This
response code enables calling parties to learn that an intermediary response code enables calling parties to learn that an intermediary
rejected their call attempt. No one will deliver, and thus no one rejected their call attempt. No one will deliver, and thus no one
will answer, the call. As a 6xx code, the caller will be aware that will answer, the call. As a 6xx code, the caller will be aware that
future attempts to contact the same User Agent Server will likely future attempts to contact the same User Agent Server will likely
fail. The initial use case driving the need for the 608 response fail. The initial use case driving the need for the 608 response
code is when the intermediary is an analytics engine. In this case, code is when the intermediary is an analytics engine. In this case,
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 22, 2019. This Internet-Draft will expire on December 30, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 45 skipping to change at page 2, line 45
4.2. Web Site jCard . . . . . . . . . . . . . . . . . . . . . 15 4.2. Web Site jCard . . . . . . . . . . . . . . . . . . . . . 15
4.3. Multi-modal jCard . . . . . . . . . . . . . . . . . . . . 16 4.3. Multi-modal jCard . . . . . . . . . . . . . . . . . . . . 16
4.4. Legacy Interoperability . . . . . . . . . . . . . . . . . 16 4.4. Legacy Interoperability . . . . . . . . . . . . . . . . . 16
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
5.1. SIP Response Code . . . . . . . . . . . . . . . . . . . . 18 5.1. SIP Response Code . . . . . . . . . . . . . . . . . . . . 18
5.2. SIP Feature-Capability Indicator . . . . . . . . . . . . 18 5.2. SIP Feature-Capability Indicator . . . . . . . . . . . . 18
5.3. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 19 5.3. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 19
5.4. Call-Info Purpose . . . . . . . . . . . . . . . . . . . . 19 5.4. Call-Info Purpose . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . 22 8.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
The IETF has been addressing numerous issues surrounding how to The IETF has been addressing numerous issues surrounding how to
handle unwanted and, depending on the jurisdiction, illegal calls handle unwanted and, depending on the jurisdiction, illegal calls
[RFC5039]. Technologies such as STIR [RFC7340] and SHAKEN [SHAKEN] [RFC5039]. STIR [RFC7340] and SHAKEN [SHAKEN] address the
address the cryptographic signing and attestation, respectively, of cryptographic signing and attestation, respectively, of signaling to
signaling to ensure the integrity and authenticity of the asserted ensure the integrity and authenticity of the asserted caller
caller identity. identity.
This document describes a new SIP response code, 608, which allows This document describes a new Session Initiation Protocol (SIP)
calling parties to learn that an intermediary rejected their call. [RFC3261] response code, 608, which allows calling parties to learn
As described below, we need a distinct indicator to differentiate that an intermediary rejected their call. As described below, we
between a user rejection and an intermediary's rejection of a call. need a distinct indicator to differentiate between a user rejection
In some jurisdictions, service providers may not be permitted to and an intermediary's rejection of a call. In some jurisdictions,
block calls, even if unwanted by the user, unless there is an service providers may not be permitted to block calls, even if
explicit user request. Moreover, users may misidentify the nature of unwanted by the user, unless there is an explicit user request.
a caller. Moreover, users may misidentify the nature of a caller.
For example, a legitimate caller may call a user who finds the call For example, a legitimate caller may call a user who finds the call
to be unwanted. However, instead of marking the call as unwanted, to be unwanted. However, instead of marking the call as unwanted,
the user may mark the call as illegal. With that information, an the user may mark the call as illegal. With that information, an
analytics engine may determine to block all calls from that source. analytics engine may determine to block all calls from that source.
However, in some jurisdictions blocking calls from that source for However, in some jurisdictions blocking calls from that source for
other users may not be legal. Likewise, one can envision other users may not be legal. Likewise, one can envision
jurisdictions that allow an operator to block such calls, but only if jurisdictions that allow an operator to block such calls, but only if
there is a remediation mechanism in place to address false positives. there is a remediation mechanism in place to address false positives.
Some call blocking services may return responses such as 604 (Does 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, destination's address removed from a calling database. However,
other network elements might also interpret this to mean the user other network elements might also interpret this to mean the user
truly does not exist and might result in the user not being able to truly does not exist, which might result in the user not being able
receive calls from anyone, even if wanted. In many jurisdictions, to receive calls from anyone, even if they wanted to receive the
providing such false signaling is also illegal. calls. In many jurisdictions, providing such false signaling is also
illegal.
The 608 response code addresses this need of remediating falsely The 608 response code addresses this need of remediating falsely
blocked calls. Specifically, this code informs the SIP User Agent blocked calls. Specifically, this code informs the SIP User Agent
Client (UAC) that an intermediary blocked the call and provides a Client (UAC) that an intermediary blocked the call and provides a
redress mechanism that allows callers to contact the operator of the redress mechanism that allows callers to contact the operator of the
intermediary. intermediary.
In the current call handling ecosystem, users can explicitly reject a In the current call handling ecosystem, users can explicitly reject a
call or later mark a call as being unwanted by issuing a 607 SIP call or later mark a call as being unwanted by issuing a 607 SIP
response code (Unwanted) [RFC8197]. Figure 1 and Figure 2 show the response code (Unwanted) [RFC8197]. Figure 1 and Figure 2 show the
skipping to change at page 4, line 4 skipping to change at page 4, line 5
redress mechanism that allows callers to contact the operator of the redress mechanism that allows callers to contact the operator of the
intermediary. intermediary.
In the current call handling ecosystem, users can explicitly reject a In the current call handling ecosystem, users can explicitly reject a
call or later mark a call as being unwanted by issuing a 607 SIP call or later mark a call as being unwanted by issuing a 607 SIP
response code (Unwanted) [RFC8197]. Figure 1 and Figure 2 show the response code (Unwanted) [RFC8197]. Figure 1 and Figure 2 show the
operation of the 607 SIP response code. The User Agent Server (UAS) operation of the 607 SIP response code. The User Agent Server (UAS)
indicates the call was unwanted. As [RFC8197] explains, not only indicates the call was unwanted. As [RFC8197] explains, not only
does the called party desire to reject that call, they can let their does the called party desire to reject that call, they can let their
proxy know that they consider future calls from that source unwanted. proxy know that they consider future calls from that source unwanted.
Upon receipt of the 607 response from the UAS, the proxy may send Upon receipt of the 607 response from the UAS, the proxy may send
call information to a call analytics engine. For various reasons unwanted call indicators, such as the value of the From header field
described in [RFC8197], if a network operator receives multiple and other information elements, to a call analytics engine. For
reports of unwanted calls, that may indicate that the entity placing various reasons described in [RFC8197], if a network operator
the calls is likely to be a source of unwanted calls for many people. receives multiple reports of unwanted calls, that may indicate that
As such, other customers of the service provider may want the service the entity placing the calls is likely to be a source of unwanted
provider to automatically reject calls on their behalf. calls for many people. As such, other customers of the service
provider may want the service provider to automatically reject calls
on their behalf.
Another value of the 607 rejection is presuming the proxy forwards There is another value of the 607 rejection code. Presuming the
the response code to the User Agent Client (UAC), the calling UAC or proxy forwards the response code to the User Agent Client (UAC), the
intervening proxies will also learn the user is not interested in calling UAC or intervening proxies will also learn the user is not
receiving calls from that sender. interested in receiving calls from that sender.
+-----------+ +-----------+
| Call | | Call |
| Analytics | | Analytics |
| Engine | | Engine |
+-----------+ +-----------+
^ | (likely not SIP) ^ | (likely not SIP)
| v | v
+-----------+ +-----------+
+-----+ 607 | Called | 607 +-----+ +-----+ 607 | Called | 607 +-----+
skipping to change at page 5, line 20 skipping to change at page 5, line 22
party proxy rejects the call on behalf of the user. In this party proxy rejects the call on behalf of the user. In this
situation, it would be beneficial for the caller to learn who situation, it would be beneficial for the caller to learn who
rejected the call, so they can correct the misidentification. rejected the call, so they can correct the misidentification.
+--------+ +-----------+ +--------+ +-----------+
| Called | | Call | | Called | | Call |
+-----+ | Party | | Analytics | +-----+ +-----+ | Party | | Analytics | +-----+
| UAC | | Proxy | | Engine | | UAS | | UAC | | Proxy | | Engine | | UAS |
+-----+ +--------+ +-----------+ +-----+ +-----+ +--------+ +-----------+ +-----+
| INVITE | | | | INVITE | | |
| --------------> | INVITE | | | --------------> | Is call OK? | |
| |------------------->| |
| | | |
| | Yes | |
| |<-------------------| |
| | | |
| | INVITE | |
| | ------------------------------> | | | ------------------------------> |
| | | | | | | |
| | | 607 | | | | 607 |
| | <------------------------------ | | | <------------------------------ |
| | | | | | | |
| | Unwanted call | | | | Unwanted call | |
| 607 | -----------------> | | | 607 | -----------------> | |
| <-------------- | indicator | | | <-------------- | indicators | |
| | | | | | | |
Figure 2: Unwanted (607) Ladder Diagram Figure 2: Unwanted (607) Ladder Diagram
+-----------+ +-----------+
| Call | | Call |
| Analytics | | Analytics |
| Engine | | Engine |
+-----------+ +-----------+
^ | (likely not SIP) ^ | (likely not SIP)
| v | v
+-----------+ +-----------+
+-----+ 608 | Called | +-----+ +-----+ 608 | Called | +-----+
| UAC | <--------- | Party | | UAS | | UAC | <--------- | Party | | UAS |
skipping to change at page 6, line 8 skipping to change at page 6, line 25
+-----------+ +-----------+
Figure 3: Rejected (608) Call Flow Figure 3: Rejected (608) Call Flow
In this situation, one might consider to have the intermediary use In this situation, one might consider to have the intermediary use
the 607 response code. 607 indicates to the caller the subscriber the 607 response code. 607 indicates to the caller the subscriber
does not want the call. However, [RFC8197] specifies that one of the does not want the call. However, [RFC8197] specifies that one of the
uses of 607 is to inform analytics engines that a user (human) has uses of 607 is to inform analytics engines that a user (human) has
rejected a call. The problem here is that network elements rejected a call. The problem here is that network elements
downstream from the intermediary might interpret the 607 as coming downstream from the intermediary might interpret the 607 as coming
from a user (human) that has marked the call as unwanted, as opposed from a user (human) who has marked the call as unwanted, as opposed
to coming from an algorithm using statistics or machine learning to to coming from an algorithm using statistics or machine learning to
reject the call. An algorithm can be vulnerable to an algorithm reject the call. An algorithm can be vulnerable to the base rate
subject to the base rate fallacy [BaseRate] rejecting the call. In fallacy [BaseRate] rejecting the call. In other words, those
other words, those downstream entities should not rely on another downstream entities should not rely on another entity 'deciding' the
entity 'deciding' the call is unwanted. By distinguishing between a call is unwanted. By distinguishing between a (human) user rejection
(human) user rejection and an intermediary engine's statistical and an intermediary engine's statistical rejection, a downstream
rejection, a downstream network element that sees a 607 response code network element that sees a 607 response code can weigh it as a human
can weigh it as a human rejection in its call analytics, versus rejection in its call analytics, versus deciding whether to consider
deciding whether to consider a 608 at all, and if so, weighing it a 608 at all, and if so, weighing it appropriately.
appropriately.
It is useful for blocked callers to have a redress mechanism. One It is useful for blocked callers to have a redress mechanism. One
can imagine that some jurisdictions will require it. However, we can imagine that some jurisdictions will require it. However, we
must be mindful that most of the calls that intermediaries block must be mindful that most of the calls that intermediaries block
will, in fact, be illegal and eligible for blocking. Thus, providing will, in fact, be illegal and eligible for blocking. Thus, providing
alternate contact information for a user would be counterproductive alternate contact information for a user would be counterproductive
to protecting that user from illegal communications. This is another to protecting that user from illegal communications. This is another
reason we do not propose to simply allow alternate contact reason we do not propose to simply allow alternate contact
information in a 607 response message. information in a 607 response message.
Why do we not use the same mechanism an analytics service provider Why do we not use the same mechanism an analytics service provider
offers their customers? Specifically, why not have the analytics offers their customers? Specifically, why not have the analytics
service provider allow the called party to correct a call blocked in service provider allow the called party to correct a call blocked in
error? The reason is while there is an existing relationship between error? The reason is while there is an existing relationship between
the customer (called party) and the analytics service provider, it is the customer (called party) and the analytics service provider, it is
unlikely there is a relationship between the caller and the analytics unlikely there is a relationship between the caller and the analytics
service provider. Moreover, there are numerous call blocking service provider. Moreover, there are numerous call blocking
providers in the ecosystem. As such, we need a mechanism for providers in the ecosystem. Therefore, we need a mechanism for
indicating an intermediary rejected a call that also provides contact indicating an intermediary rejected a call that also provides contact
information for the operator of that intermediary, without exposing information for the operator of that intermediary, without exposing
the target user's contact information. the target user's contact information.
The protocol described in this document uses existing SIP protocol The protocol described in this document uses existing SIP protocol
mechanisms for specifying the redress mechanism. In the Call-Info mechanisms for specifying the redress mechanism. In the Call-Info
header passed back to the UAC, we send additional information header passed back to the UAC, we send additional information
specifying a redress address. We choose to encode the redress specifying a redress address. We choose to encode the redress
address using jCard [RFC7095]. As we will see later in this address using jCard [RFC7095]. As we will see later in this
document, this information needs to have its own, application-layer document, this information needs to have its own, application-layer
integrity protection. As such, we use jCard rather than vCard integrity protection. Thus, we use jCard rather than vCard [RFC6350]
[RFC6350] as we have a marshaling mechanism for creating a JavaScript as we have a marshaling mechanism for creating a JavaScript Object
Object Notation (JSON) [RFC8259] object, such as a jCard, and a Notation (JSON) [RFC8259] object, such as a jCard, and a standard
standard integrity format for such an object, namely JSON Web integrity format for such an object, namely JSON Web Signature (JWS)
Signature (JWS) [RFC7515]. The SIP community is familiar with this [RFC7515]. The SIP community is familiar with this concept as it is
concept as it is the mechanism used by STIR [RFC8224]. the mechanism used by STIR [RFC8224].
Integrity protecting the jCard with a cryptographic signature might Integrity protecting the jCard with a cryptographic signature might
seem unnecessary at first, but it is essential to preventing seem unnecessary at first, but it is essential to preventing
potential network attacks. Suppose, for example, that one simply potential network attacks. Section 6 describes the attack and why we
passes the redress address as a header field value. One can imagine sign the jCard in more detail.
an adverse agent that maliciously spoofs a 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 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 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.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Protocol Operation 3. Protocol Operation
For clarity, this section uses the term 'intermediary' as the entity This section uses the term 'intermediary' to mean the entity that
that acts as a SIP User Agent Server (UAS) on behalf of the user in acts as a SIP User Agent Server (UAS) on behalf of the user in the
the network, as opposed to the user's UAS (colloquially, but not network, as opposed to the user's UAS (usually, but not necessarily,
necessarily, their phone). The intermediary could be a back-to-back their phone). The intermediary could be a back-to-back user agent
user agent (B2BUA) or a SIP Proxy. (B2BUA) or a SIP Proxy.
Figure 4 shows an overview of the call flow for a rejected call. Figure 4 shows an overview of the call flow for a rejected call.
+--------+ +-----------+ +--------+ +-----------+
| Called | | Call | | Called | | Call |
+-----+ | Party | | Analytics | +-----+ +-----+ | Party | | Analytics | +-----+
| UAC | | Proxy | | Engine | | UAS | | UAC | | Proxy | | Engine | | UAS |
+-----+ +--------+ +-----------+ +-----+ +-----+ +--------+ +-----------+ +-----+
| INVITE | | | | INVITE | | |
| --------------> | Information from | | | --------------> | Information from | |
skipping to change at page 8, line 30 skipping to change at page 8, line 30
3.1. Intermediary Operation 3.1. Intermediary Operation
An intermediary MAY issue the 608 response code in a failure response An intermediary MAY issue the 608 response code in a failure response
for an INVITE, MESSAGE, SUBSCRIBE, or other out-of-dialog SIP for an INVITE, MESSAGE, SUBSCRIBE, or other out-of-dialog SIP
[RFC3261] request to indicate that an intermediary rejected the [RFC3261] request to indicate that an intermediary rejected the
offered communication as unwanted by the user. An intermediary MAY offered communication as unwanted by the user. An intermediary MAY
issue the 608 as the value of the "cause" parameter of a SIP reason- issue the 608 as the value of the "cause" parameter of a SIP reason-
value in a Reason header field [RFC3326]. value in a Reason header field [RFC3326].
If an intermediary issues a 608 code and there are not indicators the 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 calling party will use the contents of the Call-Info header field for
malicious purposes (see Section 6), the intermediary MUST include a malicious purposes (see Section 6), the intermediary MUST include a
Call-Info header field in the response. Call-Info header field in the response.
If there is a Call-Info header field, it MUST have the 'purpose' If there is a Call-Info header field, it MUST have the 'purpose'
parameter of 'jwscard'. The value of the Call-Info header field MUST parameter of 'jwscard'. The value of the Call-Info header field MUST
refer to a valid JSON Web Signature (JWS [RFC7515]) encoding of a refer to a valid JSON Web Signature (JWS [RFC7515]) encoding of a
jCard [RFC7095] object. jCard [RFC7095] object. The following section describes the
construction of the JWS.
Proxies need to be mindful that a downstream intermediary may reject Proxies need to be mindful that a downstream intermediary may reject
the attempt with a 608 while other paths may still be in progress. the attempt with a 608 while other paths may still be in progress.
In this situation, the requirements stated in Section 16.7 of In this situation, the requirements stated in Section 16.7 of
[RFC3261] apply. Specifically, the proxy should cancel pending [RFC3261] apply. Specifically, the proxy should cancel pending
transactions and must not create any new branches. Note this is not transactions and must not create any new branches. Note this is not
a new requirement but simply pointing out the existing 6xx protocol a new requirement but simply pointing out the existing 6xx protocol
mechanism in SIP. mechanism in SIP.
3.2. JWS Construction 3.2. JWS Construction
skipping to change at page 9, line 27 skipping to change at page 9, line 27
corresponding to the key used to digitally sign the JWS. corresponding to the key used to digitally sign the JWS.
3.2.2. JWT Payload 3.2.2. JWT Payload
The payload contains two JSON values. The first JSON Web Token (JWT) The payload contains two JSON values. The first JSON Web Token (JWT)
claim that MUST be present is the iat (issued at) claim [RFC7519]. claim that MUST be present is the iat (issued at) claim [RFC7519].
The "iat" MUST be set to the date and time of the issuance of the 608 The "iat" MUST be set to the date and time of the issuance of the 608
response. This mandatory component protects the response from replay response. This mandatory component protects the response from replay
attacks. attacks.
The second JWT claim that MUST be present is the jcard claim. The second JWT claim that MUST be present is the "jcard" claim. The
Section 5.3 describes the registration. In the construction of the value of the jcard [RFC7095] claim is a JSON array conforming to the
jcard claim, the "jcard" MUST include at least one of the URL, EMAIL, JSON jCard data format defined in RFC7095 Section 5.3 describes the
TEL, or ADR properties. UACs supporting this specification MUST be registration. In the construction of the jcard claim, the "jcard"
prepared to receive a full jCard. Call originators (at the UAC) can MUST include at least one of the URL, EMAIL, TEL, or ADR properties.
use the information returned by the jCard to contact the intermediary UACs supporting this specification MUST be prepared to receive a full
that rejected the call to appeal the intermediary's blocking of the jCard. Call originators (at the UAC) can use the information
call attempt. What the intermediary does if the blocked caller returned by the jCard to contact the intermediary that rejected the
contacts the intermediary is outside the scope of this document. 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.
3.2.3. JWS Signature 3.2.3. JWS Signature
JWS [RFC7515] specifies the procedure for calculating the signature JWS [RFC7515] specifies the procedure for calculating the signature
over the jCard JWT. Section 4 of this document has a detailed over the jCard JWT. Section 4 of this document has a detailed
example on constructing the JWS, including the signature. example on constructing the JWS, including the signature.
3.3. UAC Operation 3.3. UAC Operation
A UAC conforming to this specification MUST include the sip.608 A UAC conforming to this specification MUST include the sip.608
feature capability indicator in the Feature-Caps header field of the feature capability indicator in the Feature-Caps header field of the
INVITE request. INVITE request.
Upon receiving a 608 response, UACs perform normal SIP processing for Upon receiving a 608 response, UACs perform normal SIP processing for
6xx responses. 6xx responses.
As for the disposition of the jCard itself, the UAC MUST check the As for the disposition of the jCard itself, the UAC MUST check the
"iat" claim in the JWT. As noted in Section 3.2.3, we are concerned "iat" claim in the JWT. As noted in Section 3.2.3, we are concerned
about replay attacks. As such, the UAC MUST reject jCards that come about replay attacks. Therefore, the UAC MUST reject jCards that
with an expired "iat". The definition of "expired" is a matter of come with an expired "iat". The definition of "expired" is a matter
local policy. A reasonable value would be on the order of a minute of local policy. A reasonable value would be on the order of a
due to clock drift and the possibility of the playing of an audio minute due to clock drift and the possibility of the playing of an
announcement before the delivery of the 608 response. audio announcement before the delivery of the 608 response.
3.4. Legacy Interoperation 3.4. Legacy Interoperation
If the UAC indicates support for 608 and the intermediary issues a 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? connecting to the SIP network via a media gateway?
We address this situation by having the first network element that 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 in the media.
See Section 3.5 for requirements on the announcement. The simple See Section 3.5 for requirements on the announcement. The simple
rule is a network element that inserts the sip.608 feature capability rule is a network element that inserts the sip.608 feature capability
MUST be able to convey at a minimum how to contact the operator of MUST be able to convey at a minimum how to contact the operator of
skipping to change at page 11, line 38 skipping to change at page 11, line 38
this specification does not mandate how to convey that information. this specification does not mandate how to convey that information.
Let us take the case where a telecommunications service provider 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 (SDP) [RFC4566] to result codecs in the Session Description Protocol (SDP) [RFC4566] to result
in an audio announcement. However, if the INVITE only indicated a in an audio announcement. Likewise, if the INVITE only indicated a
real-time text codec and the network element can render the real-time text codec [RFC4103] and the network element can render the
information in the requested media format, the network element MUST information in the requested media format, the network element should
send the information in a text format, not an audio format. send the information in a text format.
It is also possible for the network element inserting the sip.608 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 for the outbound calling proxy to digest the Call-Info information
and handle the information digitally, rather than 'transcoding' the and handle the information digitally, rather than 'transcoding' the
Call-Info information for presentation to the caller. Call-Info information for presentation to the caller.
4. Examples 4. Examples
These examples are not normative, do not include all protocol These examples are not normative, do not include all protocol
elements, and may have errors. Review the protocol documents for elements, and may have errors. Review the protocol documents for
actual syntax and semantics of the protocol elements. actual syntax and semantics of the protocol elements.
4.1. Full Exchange 4.1. Full Exchange
Given an INVITE (shamelessly taken from [SHAKEN]): Given an INVITE, shamelessly taken from [SHAKEN], with the line
breaks in the Identity header field for display purposes only:
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: Identity: eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2V
eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2VuIiwieDV1I uIiwieDV1IjoiaHR0cDovL2NlcnQuZXhhbXBsZTIubmV0L2V4YW1wbGUuY2VydCJ9.eyJ
joiaHR0cDovL2NlcnQtYXV0aC5wb2Muc3lzLmNvbWNhc3QubmV0L2V4YW1wbGUuY2VydC hdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6IisxMjE1NTU1MDExMyJ9LCJpYXQiOiIxNDcx
J9eyJhdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6IisxMjE1NTU1MTIxMyJ9LCJpYXQiOiI Mzc1NDE4Iiwib3JpZyI6eyJ0biI6IisxMjE1NTU1MDExMiJ9LCJvcmlnaWQiOiIxMjNlN
xNDcxMzc1NDE4Iiwib3JpZyI6eyJ0biI64oCdKzEyMTU1NTUxMjEyIn0sIm9yaWdpZCI6 DU2Ny1lODliLTEyZDMtYTQ1Ni00MjY2NTU0NDAwMCJ9.QAht_eFqQlaoVrnEV56Qly-OU
IjEyM2U0NTY3LWU4OWItMTJkMy1hNDU2LTQyNjY1NTQ0MDAwMCJ9._28kAwRWnheXyA6n tsDGifyCcpYjWcaR661Cz1hutFH2BzIlDswTahO7ujjqsWjeoOb4h97whTQJg;info=
Y4MvmK5JKHZH9hSYkWI4g75mnq9Tj2lW4WPm0PlvudoGaj7wM5XujZUTb_3MA4modoDtC <http://cert.example2.net/example.cert>;alg=ES256
A;info=<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
An intermediary could reply: An intermediary could reply:
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
The location https://block.example.net/complaint-jws resolves to a The location https://block.example.net/complaint-jws resolves to a
JWS. One would construct the JWS as follows. JWS. One would construct the JWS as follows.
The JWS header of this example jCard could be: The JWS header of this example jCard could be:
{ {"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"
}
Now, let us construct a minimal jCard. For this example, the jCard Now, let us construct a minimal jCard. For this example, the jCard
refers the caller to an email address, bitbucket@blocker.example.net: refers the caller to an email address,
remediation@blocker.example.net:
["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", "bitbucket@blocker.example.net"] "text", "remediation@blocker.example.net"]
] ]
] ]
With this jCard, we can now construct the JWT: With this jCard, we can now construct the JWT:
{ {
"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", "bitbucket@blocker.example.net"] "text", "remediation@blocker.example.net"]
] ]
] ]
} }
To calculate the signature, we need to encode the JSON Object Signing To calculate the signature, we need to encode the JSON Object Signing
and Encryption (JOSE) header and JWT into base64url. As an 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 MUST be prepared to receive pretty-printed,
compact, or bizarrely formatted JSON. For the purposes of this compact, or bizarrely formatted JSON. For the purposes of this
example, we leave the objects with pretty whitespace. Speaking of example, we leave the objects with pretty whitespace. Speaking of
pretty vs. machine formatting, these examples have line breaks in the pretty vs. machine formatting, these examples have line breaks in the
base64url encodings for ease of publication in the RFC format. 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
skipping to change at page 14, line 12 skipping to change at page 14, line 14
To calculate the signature, we need to encode the JSON Object Signing To calculate the signature, we need to encode the JSON Object Signing
and Encryption (JOSE) header and JWT into base64url. As an 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 MUST be prepared to receive pretty-printed,
compact, or bizarrely formatted JSON. For the purposes of this compact, or bizarrely formatted JSON. For the purposes of this
example, we leave the objects with pretty whitespace. Speaking of example, we leave the objects with pretty whitespace. Speaking of
pretty vs. machine formatting, these examples have line breaks in the pretty vs. machine formatting, these examples have line breaks in the
base64url encodings for ease of publication in the RFC format. 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. As such, would affect the calculation of the signature. Implementations MUST
implementations MUST NOT insert line breaks into the base64url NOT insert line breaks into the base64url encodings of the JOSE
encodings of the JOSE header or JWT. This also means UACs MUST be header or JWT. This also means UACs MUST be prepared to receive
prepared to receive arbitrarily long octet streams from the URI arbitrarily long octet streams from the URI referenced by the Call-
referenced by the Call-Info SIP header. Info SIP header.
base64url of JOSE header: base64url of JOSE header:
eyB7ImFsZyI6IkVTMjU2In0sCiAgeyJ0eXAiOiJ2Y2FyZCtqc29uIn0sCiAgeyJ4 eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJkK2pzb24iLCJ4NXUiOiJodHRwczov
NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0g L2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0=
fQo
base64url of JWT: base64url of JWT:
ewogICJpYXQiOjE1NDYwMDg2OTgsCiAgImpjYXJkIjpbInZjYXJkIiwKICAgIFsK eyJpYXQiOjE1NDYwMDg2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2ZXJzaW9uIix7
ICAgICAgWyJ2ZXJzaW9uIiwge30sICJ0ZXh0IiwgIjQuMCJdLAogICAgICBbImZu fSwidGV4dCIsIjQuMCJdLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2NhbGwgQWRqdWRp
Iiwge30sICJ0ZXh0IiwgIlJvYm9jYWxsIEFkanVkaWNhdGlvbiJdLAogICAgICBb Y2F0aW9uIl0sWyJlbWFpbCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0IiwicmVtZWRp
ImVtYWlsIiwgeyJ0eXBlIjoid29yayJ9LCAKICAgICAgICAgICAgICAgICJ0ZXh0 YXRpb25AYmxvY2tlci5leGFtcGxlLm5ldCJdXV19
IiwgImJpdGJ1Y2tldEBibG9ja2VyLmV4YW1wbGUubmV0Il0KICAgIF0KICBdCn0K
In this case, the object to sign (remembering this is just a single, In this case, the object to sign (remembering this is just a single,
long line; the line breaks are for ease of review but do not appear long line; the line breaks are for ease of review but do not appear
in the actual object) is as follows: in the actual object) is as follows:
eyB7ImFsZyI6IkVTMjU2In0sCiAgeyJ0eXAiOiJ2Y2FyZCtqc29uIn0sCiAgeyJ4 eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJk
NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0g K2pzb24iLCJ4NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9r
fQo ZXkuY2VyIn0.eyJpYXQiOjE1NDYwMDg2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2
. ZXJzaW9uIix7fSwidGV4dCIsIjQuMCJdLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2Nh
ewogICJpYXQiOjE1NDYwMDg2OTgsCiAgImpjYXJkIjpbInZjYXJkIiwKICAgIFsK bGwgQWRqdWRpY2F0aW9uIl0sWyJlbWFpbCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0
ICAgICAgWyJ2ZXJzaW9uIiwge30sICJ0ZXh0IiwgIjQuMCJdLAogICAgICBbImZu IiwicmVtZWRpYXRpb25AYmxvY2tlci5leGFtcGxlLm5ldCJdXV19
Iiwge30sICJ0ZXh0IiwgIlJvYm9jYWxsIEFkanVkaWNhdGlvbiJdLAogICAgICBb
ImVtYWlsIiwgeyJ0eXBlIjoid29yayJ9LCAKICAgICAgICAgICAgICAgICJ0ZXh0
IiwgImJpdGJ1Y2tldEBibG9ja2VyLmV4YW1wbGUubmV0Il0KICAgIF0KICBdCn0K
We use the following X.509 PKCS #8-encoded ECDSA private key, also We use the following X.509 PKCS #8-encoded ECDSA key, also
shamelessly taken from [SHAKEN]), as an example key for signing the shamelessly taken from [SHAKEN]), as an example key for signing the
hash of the above text. Do NOT use this key in real life! It is for 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 example purposes only. At the very least, we would strongly
recommend encrypting the key at rest. recommend encrypting the key at rest.
-----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-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8HNbQd/TmvCKwPKHkMF9fScavGeH
78YTU8qLS8I5HLHSSmlATLcslQMhNC/OhlWBYC626nIlo7XeebYS7Sb37g==
-----END PUBLIC KEY-----
The resulting JWS, using the above key on the above object, renders The resulting JWS, using the above key on the above object, renders
the following ECDSA P-256 SHA-256 digital signature. the following ECDSA P-256 SHA-256 digital signature.
MEUCIQCF2nv/eKvnGQNELZglQTpWbYtzbEf97xH4zKnkLx7S0QIgIl2f5ehMOwjM 7uz2SADRvPFOQOO_UgF2ZTUjPlDTegtPrYB04UHBMwBD6g9AmL
TS+skjf1163ihH5+yIHQS3quklEt/9o 5harLJdTKDSTtH-LOV1jwJaGRUOUJiwP27ag
Thus, the JWS stored at https://blocker.example.net/complaints-jws, Thus, the JWS stored at https://blocker.example.net/complaints-jws,
would contain: would contain:
eyB7ImFsZyI6IkVTMjU2In0sCiAgeyJ0eXAiOiJ2Y2FyZCtqc29uIn0sCiAgeyJ4 eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJkK2pzb24iLCJ4NXUiOiJodHRwczovL
NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0g 2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0.eyJpYXQiOjE1NDYwMD
fQo=.ewogICJpYXQiOjE1NDYwMDg2OTgsCiAgImpjYXJkIjpbInZjYXJkIiwKICA g2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2ZXJzaW9uIix7fSwidGV4dCIsIjQuMCJ
gIFsKICAgICAgWyJ2ZXJzaW9uIiwge30sICJ0ZXh0IiwgIjQuMCJdLAogICAgICB dLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2NhbGwgQWRqdWRpY2F0aW9uIl0sWyJlbWFp
bImZuIiwge30sICJ0ZXh0IiwgIlJvYm9jYWxsIEFkanVkaWNhdGlvbiJdLAogICA bCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0IiwicmVtZWRpYXRpb25AYmxvY2tlci5le
gICBbImVtYWlsIiwgeyJ0eXBlIjoid29yayJ9LCAKICAgICAgICAgICAgICAgICJ GFtcGxlLm5ldCJdXV19.7uz2SADRvPFOQOO_UgF2ZTUjPlDTegtPrYB04UHBMwBD6
0ZXh0IiwgImJpdGJ1Y2tldEBibG9ja2VyLmV4YW1wbGUubmV0Il0KICAgIF0KICB g9AmL5harLJdTKDSTtH-LOV1jwJaGRUOUJiwP27ag
dCn0K.MEUCIQCF2nv/eKvnGQNELZglQTpWbYtzbEf97xH4zKnkLx7S0QIgIl2f5e
hMOwjMTS+skjf1163ihH5+yIHQS3quklEt/9o
4.2. Web Site jCard 4.2. Web Site jCard
For an intermediary that provides a Web site for adjudication, the For an intermediary that provides a Web site for adjudication, the
jCard could contain the following. Note we do not show the jCard could contain the following. Note we do not show the
calculation of the JWS; the URI reference in the Call-Info header calculation of the JWS; the URI reference in the Call-Info header
field would be to the JWS of the signed jCard. field would be to the JWS of the signed jCard.
["vcard", ["vcard",
[ [
skipping to change at page 16, line 38 skipping to change at page 16, line 38
Figure 5 depicts a call flow illustrating legacy interoperability. Figure 5 depicts a call flow illustrating legacy interoperability.
In this non-normative example, we see a UAC that does not support the 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 full semantics for 608. However, there is an SBC that does support
608. Per [RFC6809], the SBC can insert "*;+sip.608" into the 608. Per [RFC6809], the SBC can insert "*;+sip.608" into the
Feature-Caps header field for the INVITE. When the intermediary, Feature-Caps header field for the INVITE. When the intermediary,
labeled "Called Party Proxy" in the figure, rejects the call, it labeled "Called Party Proxy" in the figure, rejects the call, it
knows it can simply perform the processing described in this knows it can simply perform the processing described in this
document. Since the intermediary saw the sip.608 feature capability, document. Since the intermediary saw the sip.608 feature capability,
it knows it does not need to send any media describing whom to it knows it does not need to send any media describing whom to
contact in the event of an erroneous rejection. 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.
+---------+ +---------+
| Call | | Call |
|Analytics| |Analytics|
| Engine | | Engine |
+--+--+---+ +--+--+---+
^ | ^ |
| | | |
| v | v
+-+--+-+ +-+--+-+
+---+ +-----+ +---+ +-----+ +-----+ |Called| +---+ +-----+ +---+ +-----+ +-----+ |Called|
|UAC+--->+Proxy+--->+SBC+--->+Proxy+--->+Proxy+--->+Party | |UAC+----+Proxy+----+SBC+----+Proxy+----+Proxy+----+Party |
+---+ +-----+ +---+ +-----+ +-----+ |Proxy | +---+ +-----+ +---+ +-----+ +-----+ |Proxy |
| +------+ | | +------+
| INVITE | | | INVITE | |
|------------------>| | |------------------>| |
| | INVITE | | | INVITE |
| |------------------------------>| | |------------------------------>|
| | Feature-Caps: *;+sip.608 | | | Feature-Caps: *;+sip.608 |
| | | | | |
| | 608 Rejected | | | 608 Rejected |
| |<------------------------------| | |<------------------------------|
| 183 | Call-Info: <...> | | 183 | Call-Info: <...> |
|<------------------| [path for Call-Info elided | |<------------------| [path for Call-Info elided |
skipping to change at page 20, line 5 skipping to change at page 20, line 5
attempts, may change their call behavior to defeat call blocking attempts, may change their call behavior to defeat call blocking
systems. The second, and more significant risk, is that by providing systems. The second, and more significant risk, is that by providing
a contact in the Call-Info header field, the intermediary may be a contact in the Call-Info header field, the intermediary may be
giving the malicious caller a vector for attack. In other words, the giving the malicious caller a vector for attack. In other words, the
intermediary will be publishing an address that a malicious actor may intermediary will be publishing an address that a malicious actor may
use to launch an attack on the intermediary. Because of this, use to launch an attack on the intermediary. Because of this,
intermediary operators may wish to configure their response to only intermediary operators may wish to configure their response to only
include a Call-Info header field for INVITE or other signed include a Call-Info header field for INVITE or other signed
initiating methods and that pass validation by STIR [RFC8224]. initiating methods and that pass validation by STIR [RFC8224].
Another risk is for an attacker to flood a proxy that supports the Another risk is as follows. Consider an attacker that floods a proxy
sip.608 feature with INVITE requests that lack the sip.608 feature that supports the sip.608 feature. However, the SDP in the INVITE
capability to direct the SDP to a victim's device. Because the 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 mechanism described here can result in sending an audio file to the
target of the SDP, an attacker could use the mechanism described by target of the SDP, an attacker could use the mechanism described by
this document as an amplification attack, given a SIP INVITE can be 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 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 remediation for this is for devices that insert a sip.608 feature
capability only transmit media to what is highly likely to be the 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 actual source of the call attempt. A method for this is to only play
media in response to a STIR [RFC8224]-signed INVITE that passes media in response to a STIR-signed INVITE that passes validation.
validation. Beyond requiring a valid STIR signature on the INVITE, Beyond requiring a valid STIR signature on the INVITE, the
the intermediary can also use remediation procedures such as doing intermediary can also use remediation procedures such as doing the
the connectivity checks specified by Interactive Connectivity connectivity checks specified by Interactive Connectivity
Establishment [RFC8445]. Presumably if the target did not request Establishment [RFC8445]. If the target did not request the media,
the media, the check will fail. the check will fail.
Yet another risk is a malicious intermediary that generates a Yet another risk is a malicious intermediary that generates a
malicious 608 response with a jCard referring to a malicious agent. 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 For example, the recipient of a 608 may receive a TEL URI in the
vCard. When the recipient calls that address, the malicious agent vCard. When the recipient calls that address, the malicious agent
could ask for personally identifying information. However, instead could ask for personally identifying information. However, instead
of using that information to verify the recipient's identity, they of using that information to verify the recipient's identity, they
are phishing the information for nefarious ends. As such, we are phishing the information for nefarious ends. A similar scenario
strongly recommend the recipient validates to whom they are can unfold if the malicious agent inserts a URI that points to a
communicating with if asking to adjudicate an erroneously rejected phishing or other site. As such, we strongly recommend the recipient
call attempt. Since we may also be concerned about intermediate validates to whom they are communicating with if asking to adjudicate
nodes modifying contact information, we can address both issues with an erroneously rejected call attempt. Since we may also be concerned
a single solution. The remediation is to require the intermediary to about intermediate nodes modifying contact information, we can
sign the jCard. Signing the jCard provides integrity protection. In address both issues with a single solution. The remediation is to
addition, one can imagine mechanisms such as used by SHAKEN [SHAKEN] require the intermediary to sign the jCard. Signing the jCard
to use signing certificate issuance as a mechanism for traceback to provides integrity protection. In addition, one can imagine
the entity issuing the jCard, for example tying the identity of the mechanisms such as used by SHAKEN [SHAKEN].
subject of the certificate to the To header field of the initial SIP
request, as if the intermediary was vouching for the From header Similarly, one can imagine an adverse agent that maliciously spoofs a
field of a SIP request with that identity. Note that we are only 608 response with a victim's contact address to many active callers,
protecting against a malicious intermediary and not a hidden 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 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.
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 the identity of the subject of
the certificate relates to the To header field of the initial SIP
request, similar to validating 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 attack"). intermediary attack (formerly known as a "man in the middle attack").
As such, we only need to ensure the signature is fresh, which is why Thus, we only need to ensure the signature is fresh, which is why we
we include "iat". For most implementations, we assume that the include "iat". For most implementations, we assume that the
intermediary has a single set of contact points and will generate 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 jCard on demand. As such, there is no need to directly correlate
HTTPS fetches to specific calls. However, since the intermediary is HTTPS fetches to specific calls. However, since the intermediary is
in control of the jCard and Call-Info response, an intermediary may 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 choose to encode per-call information in the URI returned in a given
608 response. However, if the intermediary does go that route, the 608 response. However, if the intermediary does go that route, the
intermediary MUST use a non-deterministic reference mechanism and be intermediary MUST use a non-deterministic URI reference mechanism and
prepared to return dummy responses so that attackers attempting to be prepared to return dummy responses to URI requests referencing
glean call metadata by guessing calls will not get any actionable calls that do not exist so that attackers attempting to glean call
information from the HTTPS GET. metadata by guessing URI's (and thus calls) will not get any
actionable information from the HTTPS GET.
Since the decision of whether to include Call-Info in the 608 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 legitimate caller can ascertain whom to contact without including
such information in the 608. For example, in some jurisdictions, if such information in the 608. For example, in some jurisdictions, if
only the terminating service provider can be the intermediary, the only the terminating service provider can be the intermediary, the
caller can look up who the terminating service provider is based on caller can look up who the terminating service provider is based on
the routing information for the dialed number. As such, the Call- the routing information for the dialed number. Thus, the Call-Info
Info jCard could be redundant information. However, the factors jCard could be redundant information. However, the factors going
going into a particular service provider's or jurisdiction's choice into a particular service provider's or jurisdiction's choice of
of whether to include Call-Info is outside the scope of this whether to include Call-Info is outside the scope of this document.
document.
7. Acknowledgements 7. Acknowledgements
This document liberally lifts from [RFC8197] in its text and This document liberally lifts from [RFC8197] in its text and
structure. However, the mechanism and purpose of 608 is quite structure. However, the mechanism and purpose of 608 is quite
different than 607. Any errors are the current editor's and not the 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 editor of RFC8197. Thanks also go to Ken Carlberg of the FCC, Russ
Housley, Paul Kyzivat, and Tolga Asveren for their suggestions on Housley, Paul Kyzivat, and Tolga Asveren for their suggestions on
improving the draft. Tolga's suggestion to provide a mechanism for improving the draft. Tolga's suggestion to provide a mechanism for
legacy interoperability served to expand the draft by 50%. In legacy interoperability served to expand the draft by 50%. In
addition, Tolga came up with the jCard attack. Finally, Christer addition, Tolga came up with the jCard attack. Finally, Christer
Holmberg as always provided a close reading and fixed a SIP feature Holmberg as always provided a close reading and fixed a SIP feature
capability bug found by Yehoshua Gev. capability bug found by Yehoshua Gev.
Of course, we appreciated the close read and five pages of comments Of course, we appreciated the close read and five pages of comments
from our estimable Area Director, Adam Roach. 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.
Finally, Bhavik Nagda provided clarifying edits as well and more Finally, Bhavik Nagda provided clarifying edits as well and more
especially wrote and tested an implementation of the 608 response especially wrote and tested an implementation of the 608 response
code in Kamailio. Code is available at <https://github.com/ code in Kamailio. Code is available at <https://github.com/
nagdab/608_Implementation> . nagdab/608_Implementation>. Grace Chuan from MIT regenerated and
verified the JWT while working at the FCC.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 23, line 10 skipping to change at page 23, line 37
[BaseRate] [BaseRate]
Bar-Hillel, M., "The Base-Rate Fallacy in Probability Bar-Hillel, M., "The Base-Rate Fallacy in Probability
Judgements", 4 1977, < Judgements", 4 1977, <
https://apps.dtic.mil/docs/citations/ADA045772>. https://apps.dtic.mil/docs/citations/ADA045772>.
[ITU.E.180.1998] [ITU.E.180.1998]
International Telecommunications Union, "Technical International Telecommunications Union, "Technical
characteristics of tones for the telephone service", characteristics of tones for the telephone service",
ITU Recommendation E.180/Q.35, March 1998. ITU Recommendation E.180/Q.35, March 1998.
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text
Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005,
<https://www.rfc-editor.org/info/rfc4103>.
[RFC4240] Burger, E., Ed., Van Dyke, J., and A. Spitzer, "Basic [RFC4240] Burger, E., Ed., Van Dyke, J., and A. Spitzer, "Basic
Network Media Services with SIP", RFC 4240, Network Media Services with SIP", RFC 4240,
DOI 10.17487/RFC4240, December 2005, DOI 10.17487/RFC4240, December 2005,
<https://www.rfc-editor.org/info/rfc4240>. <https://www.rfc-editor.org/info/rfc4240>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <https://www.rfc-editor.org/info/rfc4566>. July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation
 End of changes. 54 change blocks. 
188 lines changed or deleted 217 lines changed or added

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