A Session Initiation Protocol (SIP) Response Code for Rejected CallsGeorgetown University37th & O St, NWWashingtonDC20057United States of Americaeburger@standardstrack.comMassachusetts Institute of Technology77 Massachusetts AvenueCambridgeMA02139United States of Americanagdab@gmail.com
RAI
SIPCORESTIRSIPCOREIANAThis document defines the 608 (Rejected) Session 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 thus answer, 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 response code in which a human at the target User Agent Server
indicates the user did not want the call. In some jurisdictions, 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.Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
. Introduction
. Terminology
. Protocol Operation
. Intermediary Operation
. JWS Construction
. JOSE Header
. JWT Payload
. JWS Signature
. UAC Operation
. Legacy Interoperation
. Announcement Requirements
. Examples
. Full Exchange
. Web Site jCard
. Multi-modal jCard
. Legacy Interoperability
. IANA Considerations
. SIP Response Code
. SIP Feature-Capability Indicator
. JSON Web Token Claim
. Call-Info Purpose
. Security Considerations
. References
. Normative References
. Informative References
Acknowledgements
Authors' Addresses
IntroductionThe IETF has been addressing numerous issues surrounding how to
handle unwanted and, depending on the jurisdiction, illegal calls . Secure Telephone Identity Revisited
(STIR) and Signature-based
Handling of Asserted information using toKENs (SHAKEN) address the cryptographic signing and
attestation, respectively, of signaling to ensure the integrity and
authenticity of the asserted caller identity.This document describes a new Session Initiation Protocol (SIP) 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.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
some jurisdictions, 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.Some call-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.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.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 response code
(Unwanted). Figures
and show the operation
of the 607 SIP response code. The User Agent Server (UAS) indicates the
call was unwanted. As
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 , 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.There is another value of the 607 rejection code. Presuming the proxy
forwards the response code to the UAC, the calling UAC or intervening
proxies will also learn the user is not interested in receiving calls
from that sender.Unwanted (607) Call Flow
+-----------+
| Call |
| Analytics |
| Engine |
+-----------+
^ | (likely not SIP)
| v
+-----------+
+-----+ 607 | Called | 607 +-----+
| UAC | <--------- | Party | <-------- | UAS |
+-----+ | Proxy | +-----+
+-----------+
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.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.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. 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 the call so they can correct the
misidentification.Unwanted (607) Ladder Diagram
+--------+ +-----------+
| Called | | Call |
+-----+ | Party | | Analytics | +-----+
| UAC | | Proxy | | Engine | | UAS |
+-----+ +--------+ +-----------+ +-----+
| INVITE | | |
| --------------> | Is call OK? | |
| |------------------->| |
| | | |
| | Yes | |
| |<-------------------| |
| | | |
| | INVITE | |
| | ------------------------------> |
| | | |
| | | 607 |
| | <------------------------------ |
| | | |
| | Unwanted call | |
| 607 | -----------------> | |
| <-------------- | indicators | |
| | | |
Rejected (608) Call Flow
+-----------+
| Call |
| Analytics |
| Engine |
+-----------+
^ | (likely not SIP)
| v
+-----------+
+-----+ 608 | Called | +-----+
| UAC | <--------- | Party | | UAS |
+-----+ | Proxy | +-----+
+-----------+
In this situation, one might consider having the intermediary use the
607 response code. 607 indicates to the caller that the subscriber does
not want the call. However,
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 rejecting
the call. In other words, those downstream entities should not rely on
another entity "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.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.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 that intermediary without exposing the target user's
contact information.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 jCard. As we will see later in
this document, this information needs to have its own application-layer
integrity protection. Thus, we use jCard rather than vCard, as we have a marshaling
mechanism for creating a JavaScript Object Notation (JSON) object, such as a jCard,
and a standard integrity format for such an object, namely, JSON Web
Signature (JWS). The SIP
community is familiar with this concept as it is the mechanism used by
STIR.Integrity protecting the jCard with a cryptographic signature might
seem unnecessary at first, but it is essential to preventing potential
network attacks. describes
the attack and why we sign the jCard in more detail.Terminology The key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are
to be interpreted as described in BCP 14 when, and only when, they appear in all
capitals, as shown here. Protocol OperationThis section uses the term "intermediary" to mean the entity that
acts as a SIP UAS on behalf of the user in the network as opposed to the
user's UAS (usually, but not necessarily, their phone). The intermediary
could be a back-to-back user agent (B2BUA) or a SIP Proxy. shows an overview of the
call flow for a rejected call.Rejected (608) Ladder Diagram
+--------+ +-----------+
| Called | | Call |
+-----+ | Party | | Analytics | +-----+
| UAC | | Proxy | | Engine | | UAS |
+-----+ +--------+ +-----------+ +-----+
| INVITE | | |
| --------------> | Is call OK? | |
| |------------------->| |
| | | |
| | Yes | |
| |<-------------------| |
| | | |
| | INVITE | |
| | ------------------------------> |
| | | |
| | | 607 |
| | <------------------------------ |
| | | |
| | Unwanted call | |
| 607 | -----------------> | |
| <-------------- | indicators | |
| | | |
Intermediary OperationAn intermediary MAY issue the 608 response code in a
failure response for an INVITE, MESSAGE, SUBSCRIBE, or other
out-of-dialog SIP
request to indicate that an intermediary rejected the offered
communication as unwanted by the user. An intermediary
MAY issue the 608 as the value of the "cause" parameter
of a SIP reason-value in a Reason header field .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 ), the intermediary MUST include a
Call-Info header field in the response.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 refer to a valid JSON Web Signature
(JWS) encoding of a jCard object. The following
section describes the construction of the JWS.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 in 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.JWS ConstructionThe intermediary constructs the JWS of the jCard as follows.JOSE HeaderThe Javascript Object Signing and Encryption (JOSE) header
MUST include the typ, alg, and x5u parameters from
JWS. The typ
parameter MUST have the value "vcard+json".
Implementations MUST support ES256 as JSON Web
Algorithms (JWA) defines
it and MAY support other registered signature
algorithms. Finally, the x5u parameter MUST be a URI
that resolves to the public key certificate corresponding to the key
used to digitally sign the JWS.JWT PayloadThe payload contains two JSON values. The first JSON Web Token
(JWT) claim that MUST be present is the "iat" (issued at) claim.
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 attacks.The second JWT claim that MUST be present is the
"jcard" claim. The value of the jcard claim is a JSON array conforming to
the JSON jCard data format defined in . describes the registration. In
the construction of the jcard claim, the "jcard" MUST
include at least one of the URL, EMAIL, TEL, or ADR properties. UACs
supporting this specification MUST 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.JWS SignatureJWS specifies the
procedure for calculating the signature over the jCard JWT. of this document has a detailed
example on constructing the JWS, including the signature.UAC OperationA UAC conforming to this specification MUST include
the sip.608 feature-capability indicator in the Feature-Caps header
field of the INVITE request.Upon receiving a 608 response, UACs perform normal SIP processing
for 6xx responses.As for the disposition of the jCard itself, the UAC
MUST check the "iat" claim in the JWT. As noted in
, we are concerned about replay
attacks. Therefore, the UAC MUST 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.Legacy InteroperationIf 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-switched network
connecting to the SIP network via a media gateway?We address this situation by having the first network element that
conforms with this specification play an announcement. See for requirements on the
announcement. The simple rule is a network element that inserts the
sip.608 feature capability MUST be able to convey at a
minimum how to contact the operator of the intermediary that rejected
the call attempt.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" a virtual sip.608
feature capability. If the caveats described in Sections and do not hold, the intermediary MUST
play the announcement.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 specification MUST insert
the sip.608 feature capability per the behaviors described in .Do note that even if a network element plays an announcement
describing the contents of the 608 response message, the network
element MUST forward the 608 response code message as
the final response to the INVITE.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 (SBC) , or proxy) need to understand the sip.608 feature
capability. If the other network elements conform to , they will pass
header fields such as "Feature-Caps: *;+sip.608" unmodified and
without need for upgrade.Because the ultimate disposition of the call attempt will be a
600-class response, the network element conveying the announcement in
the legacy direction MUST 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 UAC
MUST include support for 100rel in its INVITE, the network element
conveying the announcement MUST Require 100rel in the
183, and the UAC MUST issue a Provisional Response
ACKnowledgement (PRACK) to which the network element
MUST respond 200 OK PRACK.Announcement RequirementsThere are a few requirements on the element that handles the
announcement for legacy interoperation.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.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 the Session
Description Protocol (SDP) to result in an audio announcement.
Likewise, if the INVITE only indicated real-time text and the network element can
render the information in the requested media format, the network
element should send the information in a text format.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 information digitally rather than "transcoding" the
Call-Info information for presentation to the caller.ExamplesThese 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.Full ExchangeGiven an INVITE, shamelessly taken from , with the line breaks in the Identity header field
for display purposes only:
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
An intermediary could reply:
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
The location https://block.example.net/complaint-jws resolves to a
JWS. One would construct the JWS as follows.The JWS header of this example jCard could be:
{ "alg":"ES256",
"typ":"vcard+json",
"x5u":"https://certs.example.net/reject_key.cer"
}
Now, let us construct a minimal jCard. For this example, the jCard
refers the caller to an email address,
remediation@blocker.example.net:
["vcard",
[
["version", {}, "text", "4.0"],
["fn", {}, "text", "Robocall Adjudication"],
["email", {"type":"work"}, "text",
"remediation@blocker.example.net"]
]
]
With this jCard, we can now construct the JWT:{
"iat":1546008698,
"jcard":["vcard",
[
["version", {}, "text", "4.0"],
["fn", {}, "text", "Robocall Adjudication"],
["email", {"type":"work"},
"text", "remediation@blocker.example.net"]
]
]
} 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. UACs MUST 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 line breaks, and the
decoded text works just fine. However, those extra line-break octets
would affect the calculation of the signature. Implementations
MUST NOT insert line breaks into the base64url
encodings of the JOSE header or JWT. This also means UACs
MUST be prepared to receive arbitrarily long octet
streams from the URI referenced by the Call-Info header field.base64url of JOSE header:
eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJkK2pzb24iLCJ4NXUiOiJodHRwczov
L2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0=
base64url of JWT:
eyJpYXQiOjE1NDYwMDg2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2ZXJzaW9uIix7
fSwidGV4dCIsIjQuMCJdLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2NhbGwgQWRqdWRp
Y2F0aW9uIl0sWyJlbWFpbCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0IiwicmVtZWRp
YXRpb25AYmxvY2tlci5leGFtcGxlLm5ldCJdXV19
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 in
the actual object) is as follows:
eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJk
K2pzb24iLCJ4NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9r
ZXkuY2VyIn0.eyJpYXQiOjE1NDYwMDg2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2
ZXJzaW9uIix7fSwidGV4dCIsIjQuMCJdLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2Nh
bGwgQWRqdWRpY2F0aW9uIl0sWyJlbWFpbCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0
IiwicmVtZWRpYXRpb25AYmxvY2tlci5leGFtcGxlLm5ldCJdXV19
We use the following X.509 PKCS #8-encoded Elliptic Curve Digital
Signature Algorithm (ECDSA) key, also shamelessly taken from , 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.
-----BEGIN PRIVATE KEY-----
MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgi7q2TZvN9VDFg8Vy
qCP06bETrR2v8MRvr89rn4i+UAahRANCAAQWfaj1HUETpoNCrOtp9KA8o0V79IuW
ARKt9C1cFPkyd3FBP4SeiNZxQhDrD0tdBHls3/wFe8++K2FrPyQF9vuh
-----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 following ECDSA P-256 SHA-256 digital signature.
7uz2SADRvPFOQOO_UgF2ZTUjPlDTegtPrYB04UHBMwBD6g9AmL
5harLJdTKDSTtH-LOV1jwJaGRUOUJiwP27ag
Thus, the JWS stored at https://blocker.example.net/complaints-jws
would contain:
eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJkK2pzb24iLCJ4NXUiOiJodHRwczovL
2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0.eyJpYXQiOjE1NDYwMD
g2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2ZXJzaW9uIix7fSwidGV4dCIsIjQuMCJ
dLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2NhbGwgQWRqdWRpY2F0aW9uIl0sWyJlbWFp
bCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0IiwicmVtZWRpYXRpb25AYmxvY2tlci5le
GFtcGxlLm5ldCJdXV19.7uz2SADRvPFOQOO_UgF2ZTUjPlDTegtPrYB04UHBMwBD6
g9AmL5harLJdTKDSTtH-LOV1jwJaGRUOUJiwP27ag
Web Site jCardFor 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.
["vcard",
[
["version", {}, "text", "4.0"],
["fn", {}, "text", "Robocall Adjudication"],
["url", {"type":"work"},
"text", "https://blocker.example.net/adjudication-form"]
]
] Multi-modal jCardFor 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.["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"]
]
]Note that it is up to the UAC to decide which jCard contact
modality, if any, it will use.Legacy Interoperability 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 , 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.Legacy Operation
+---------+
| 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: <...> | |
| | |
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 this point, the SBC can play a prompt, either natively or
through a mechanism such as NETANN, 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.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 SR-2275 or Section 7 of ITU-T E.180), followed by "Your call
has been rejected by...", followed by a text-to-speech translation of
the FN text, followed by "You can reach them on...", followed by a
text-to-speech translation of the telephone number in the TEL
field.Note that the SBC also still sends the full 608 response code,
including the Call-Info header field, towards the UAC.IANA ConsiderationsSIP Response CodeThis document defines a new SIP response code, 608, in the
"Response Codes" subregistry of the "Session Initiation Protocol (SIP)
Parameters" registry defined in .
Response code:
608
Description:
Rejected
Reference:
RFC 8688
SIP Feature-Capability IndicatorThis document defines the feature capability, sip.608, in the "SIP
Feature-Capability Indicator Registration Tree" registry defined in
.
Name:
sip.608
Description:
This feature-capability indicator, when included in a
Feature-Caps header field of an INVITE request, indicates that the
entity associated with the indicator will be responsible for
indicating to the caller any information contained in the 608 SIP
response code, specifically, the value referenced by the Call-Info
header field.
Reference:
RFC 8688
JSON Web Token ClaimThis document defines the new JSON Web Token claim in the "JSON Web
Token Claims" subregistry created by . defines the
syntax. The required information is:
Claim Name:
jcard
Claim Description:
jCard data
Change Controller:
IESG
Reference:
RFC 8688,
Call-Info PurposeThis 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":
Header Field:
Call-Info
Parameter Name:
purpose
Predefined Values:
Yes
Reference:
RFC 8688
Security ConsiderationsIntermediary 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 defeat call-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 for
INVITE, or other signed initiating methods, that pass validation by
STIR.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 Interactive Connectivity
Establishment. If the target did not request the media, the check
will fail.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 SHAKEN.Similarly, one can imagine 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 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.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 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 intermediary
MUST 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
guessing URIs (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
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.ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.SIP: Session Initiation ProtocolThis document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK]Reliability of Provisional Responses in Session Initiation Protocol (SIP)This document specifies an extension to the Session Initiation Protocol (SIP) providing reliable provisional response messages. This extension uses the option tag 100rel and defines the Provisional Response ACKnowledgement (PRACK) method. [STANDARDS-TRACK]The Reason Header Field for the Session Initiation Protocol (SIP)The REGISTER function is used in a Session Initiation Protocol (SIP) system primarily to associate a temporary contact address with an address-of-record. This contact is generally in the form of a Uniform Resource Identifier (URI), such as Contact: <sip:alice@pc33.atlanta.com> and is generally dynamic and associated with the IP address or hostname of the SIP User Agent (UA). The problem is that network topology may have one or more SIP proxies between the UA and the registrar, such that any request traveling from the user's home network to the registered UA must traverse these proxies. The REGISTER method does not give us a mechanism to discover and record this sequence of proxies in the registrar for future use. This document defines an extension header field, "Path" which provides such a mechanism. [STANDARDS-TRACK]Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP)This specification defines a new SIP header field, Feature-Caps. The Feature-Caps header field conveys feature-capability indicators that are used to indicate support of features and capabilities for SIP entities that are not represented by the Uniform Resource Identifier (URI) of the Contact header field.SIP entities that are represented by the URI of the SIP Contact header field can convey media feature tags in the Contact header field to indicate support of features and capabilities.This specification also defines feature-capability indicators and creates a new IANA registry, "Proxy-Feature Feature-Capability Indicator Trees", for registering feature-capability indicators. [STANDARDS-TRACK]jCard: The JSON Format for vCardThis specification defines "jCard", a JSON format for vCard data. The vCard data format is a text format for representing and exchanging information about individuals and other entities, for example, telephone numbers, email addresses, structured names, and delivery addresses. JSON is a lightweight, text-based, language- independent data interchange format commonly used in Internet applications.JSON Web Signature (JWS)JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.JSON Web Algorithms (JWA)This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers.JSON Web Token (JWT)JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Informative ReferencesThe Base-Rate Fallacy in Probability JudgementsHebrew UniversityTechnical characteristics of tones for the telephone serviceITU-TRTP Payload for Text ConversationThis memo obsoletes RFC 2793; it describes how to carry real-time text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140.One payload format is described for transmitting text on a separate RTP session dedicated for the transmission of text.This RTP payload description recommends a method to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. [STANDARDS-TRACK]Basic Network Media Services with SIPIn SIP-based networks, there is a need to provide basic network media services. Such services include network announcements, user interaction, and conferencing services. These services are basic building blocks, from which one can construct interesting applications. In order to have interoperability between servers offering these building blocks (also known as Media Servers) and application developers, one needs to be able to locate and invoke such services in a well defined manner.This document describes a mechanism for providing an interoperable interface between Application Servers, which provide application services to SIP-based networks, and Media Servers, which provide the basic media processing building blocks. This memo provides information for the Internet community.SDP: Session Description ProtocolThis memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. [STANDARDS-TRACK]The Session Initiation Protocol (SIP) and SpamSpam, defined as the transmission of bulk unsolicited messages, has plagued Internet email. Unfortunately, spam is not limited to email. It can affect any system that enables user-to-user communications. The Session Initiation Protocol (SIP) defines a system for user-to- user multimedia communications. Therefore, it is susceptible to spam, just as email is. In this document, we analyze the problem of spam in SIP. We first identify the ways in which the problem is the same and the ways in which it is different from email. We then examine the various possible solutions that have been discussed for email and consider their applicability to SIP. This memo provides information for the Internet community.vCard Format SpecificationThis document defines the vCard data format for representing and exchanging a variety of information about individuals and other entities (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). This document obsoletes RFCs 2425, 2426, and 4770, and updates RFC 2739. [STANDARDS-TRACK]A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User AgentsIn many SIP deployments, SIP entities exist in the SIP signaling path between the originating and final terminating endpoints, which go beyond the definition of a SIP proxy, performing functions not defined in Standards Track RFCs. The only term for such devices provided in RFC 3261 is for a Back-to-Back User Agent (B2BUA), which is defined as the logical concatenation of a SIP User Agent Server (UAS) and User Agent Client (UAC).There are numerous types of SIP B2BUAs performing different roles in different ways; for example, IP Private Branch Exchanges (IPBXs), Session Border Controllers (SBCs), and Application Servers (ASs). This document identifies several common B2BUA roles in order to provide taxonomy other documents can use and reference.Secure Telephone Identity Problem Statement and RequirementsOver the past decade, Voice over IP (VoIP) systems based on SIP have replaced many traditional telephony deployments. Interworking VoIP systems with the traditional telephone network has reduced the overall level of calling party number and Caller ID assurances by granting attackers new and inexpensive tools to impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes, or even circumventing multi-factor authentication systems trusted by banks. Despite previous attempts to provide a secure assurance of the origin of SIP communications, we still lack effective standards for identifying the calling party in a VoIP session. This document examines the reasons why providing identity for telephone numbers on the Internet has proven so difficult and shows how changes in the last decade may provide us with new strategies for attaching a secure identity to SIP sessions. It also gives high-level requirements for a solution in this space.A SIP Response Code for Unwanted CallsThis document defines the 607 (Unwanted) SIP response code, allowing called parties to indicate that the call or message was unwanted. SIP entities may use this information to adjust how future calls from this calling party are handled for the called party or more broadly.Authenticated Identity Management in the Session Initiation Protocol (SIP)The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining a SIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer.This document obsoletes RFC 4474.The JavaScript Object Notation (JSON) Data Interchange FormatJavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) TraversalThis document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN).This document obsoletes RFC 5245.Signature-based Handling of Asserted information using toKENs (SHAKEN)ATIS/SIP Forum IP-INNI Task GroupTelcordia Notes on the NetworksTelcordiaAcknowledgementsThis document liberally lifts from 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 of RFC 8197. Thanks also go to Ken Carlberg
of the FCC, Russ Housley, Paul Kyzivat, and Tolga Asveren for their
suggestions on improving the document. Tolga's suggestion to provide a
mechanism for legacy interoperability served to expand the document by
50%. In addition, Tolga came up with the jCard attack. Finally, Christer
Holmberg, as always, provided a close reading and fixed a SIP
feature-capability bug found by Yehoshua Gev.Of course, we appreciated the close read and five pages of comments
from our estimable Area Director, Adam Roach. In addition, we received
valuable comments during IETF Last Call and JWT review from Ines Robles,
Mike Jones, and Brian Campbell, and IESG review from Alissa Cooper, Eric
Vyncke, Alexey Melnikov, Benjamin Kaduk, Barry Leiba, and with most
glee, Warren Kumari.Finally, Bhavik Nagda provided clarifying edits as well and, more
especially, wrote and tested an implementation of the 608 response code
in Kamailio. Code is available at . Grace Chuan
from MIT regenerated and verified the JWT while working at the FCC.Authors' AddressesGeorgetown University37th & O St, NWWashingtonDC20057United States of Americaeburger@standardstrack.comMassachusetts Institute of Technology77 Massachusetts AvenueCambridgeMA02139United States of Americanagdab@gmail.com