| Internet-Draft | CIV | February 2025 |
| Hao, et al. | Expires 27 August 2025 | [Page] |
This document defines an extension to the INVITE header of the Session Initiation Protocol (SIP) to support the Caller ID Verification (CIV) protocol proposed by Wang et al. in ACM Transactions on Privacy and Security (2023). CIV authenticates the caller ID of an incoming call through a challenge-and-response process. When receiving a call with a claimed phone number, the called party holds the call and sends an INVITE request to that number, carrying a short 4-digit challenge embedded as part of the caller ID. A genuine caller should receive the challenge and respond by echoing the same digits, e.g., through DTMF (Dual-Tone Multi-Frequency). The proposed extension involves two changes to the INVITE header. First, it adds a new options tag, "civ", in the Supported header field. This tag indicates that the calling party supports CIV. Second, it adds a special value "civ-veri-call" for the Purpose parameter of the Call-Info header field. This value indicates that the purpose of the INVITE request is to verify the caller ID based on CIV. Compared with STIR/SHAKEN, CIV authenticates the caller ID (not the carrier), does not require trusted certificate authorities and works with both IP and non-IP networks.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 27 August 2025.¶
Copyright (c) 2025 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 (https://trustee.ietf.org/license-info) 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
In a SIP network, it is easy to modify the caller ID using number spoofing. Sometimes, there are legitimate reasons to alter the caller ID, e.g., showing a single outgoing number for an organisation or a toll-free number for the called party to dial back. However, fraudsters and scammers frequently abuse number spoofing to hide their identity or to pretend to call from trusted sources. This has become a global problem in the Telecom industry.¶
STIR/SHAKEN [2] is perceived by many as the ultimate solution to prevent caller ID spoofing attacks. It works by attaching a digital signature (with a chain of certificates) to each outgoing call. Although the FCC describes STIR/SHAKEN as a "caller ID authentication technology" [8], technically, STIR/SHAKEN does not authenticate any caller ID. Instead, it authenticates the carrier, based on checking the carrier’s exclusive possession of a private signing key. That however solves a different problem. This mismatch in the authentication subject explains the root cause for real-world failures where the receiver accepts a digitally signed call as genuine under STIR/SHAKEN, but the caller ID is illegitimately spoofed [9].¶
In STIR/SHAKEN, an originating carrier must include a claim (or so-called attestation) as part of the signed content to say whether or not the caller is authorized to use the caller ID. However, the process the carrier must follow to carry out this important task, especially when the claimed caller ID belongs to a different carrier, is undefined. The Ofcom public consultation, published in June 2023 [11], highlighted the need for STIR/SHAKEN to have "a common numbering database", available to Telecom providers to distinguish legitimate and illegitimate modification of caller IDs, but creating and managing such a database was deemed infeasible in Ofcom’s final assessment report [12].¶
Besides the mismatch in the authentication subject, STIR/SHAKEN has two further problems. First, verifying digital signatures requires a public key infrastructure (PKI) to distribute certified public keys. All Telecom providers must trust the certificate authorities (CAs) as the root of trust and pay them for the certificate fees (the payment is typically a percentage of a Telecom provider’s annual income). However, scaling up this trust across borders is extremely difficult, if not impossible. Second, the digital signature and the chain of certificates typically involve transmitting kilobytes of digital data, which non-IP networks (SS7) are not designed to support.¶
In February 2024, after a public consultation on whether the UK should adopt STIR/SHAKEN, Ofcom published a final assessment report [12] and concluded: " our assessment is that we should not proceed with CLI authentication [STIR/SHAKEN] at this time". Ofcom's final assessment report explains the limitations of STIR/SHAKEN as covered above. The report also highlights the urgent need to investigate alternatives to STIR/SHAKEN, which motivates this document.¶
This document describes an alternative solution to STIR/SHAKEN based on a peer-reviewed paper published in ACM Transactions on Privacy and Security by Wang et al. in 2023 [6]. The alternative solution is called Caller ID Verification (CIV). While the original paper presents proof-of-concept implementations of CIV by modifying the software on the users' phones, this document proposes deploying CIV in the Telecom cloud for best performance. The CIV protocol specification remains the same.¶
Technically, CIV authenticate the caller ID, while STIR/SHAKEN authenticates the carrier. They address different authentication problems (although STIR/SHAKEN is often misdescribed - and misunderstood by many - as a "caller ID authentication technology"). The challenge-response method proposed in this document could also be used to strengthen certain aspects of STIR/SHAKEN, e.g., enabling the originating carrier to check if the caller is authorized to use a modified phone number that belongs to a different carrier. That may be more practical than using a "common numbering database" [11]. However, the details are outside the scope of this document. The document only considers the case that the terminating carrier (not the originating carrier) performs the CIV check, since in our threat model the caller ID presented by the originating carrier is not trusted (even if it comes with a digital signature).¶
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 [3] [4] when, and only when, they appear in all capitals, as shown here.¶
At a high level, CIV is inspired by a call-back verification method used in practice. To verify if the caller ID of an incoming call is genuine, the receiver may just hang up and call back the displayed number [10]. This call-back method ensures that the receiver talks to the genuine caller who owns that number. However, the manual call-back verification is slow and tedious. It may also incur a charge to the verifying party.¶
CIV follows a similar approach, but it automates the verification process in a secure and efficient manner without incurring a charge to the verifying party. In CIV, the authentication of the caller ID is defined based on checking the ownership of that number. Accordingly, it distinguishes legitimate and illegitimate modifications of the caller ID based on whether the caller owns the number: if they do, they should receive a call-back to that number and respond accordingly.¶
Supporting CIV in SIP [1] involves making two changes to the INVITE header. First, we propose a new option tag "civ" in the Supported header of INVITE. This tag indicates that the caller supports CIV. Second, we propose a new value "civ-veri-call" for the Purpose parameter in the Call-Info header of INVITE. The "civ-veri-call" value, paired with a unique resource indicator (URI) that can be the same as the URI in the TO header, indicates that the purpose of this INVITE request is to verify the caller ID in the initial call based on CIV.¶
Based on the two proposed changes, the CIV protocol in SIP works as follows.¶
The verification call needs to be matched with the initial call. This can be done implicitly or explicitly. Suppose Alice calls Bob. Within a short time period, if Alice receives a verification call with the caller ID matching Bob's number (excluding the last four digits), Alice matches this verification call to the initial call, and processes the challenge accordingly. This matching is implicit. Wherever possible, we recommend to implement an explicit matching method below.¶
The explicit matching can be done based on the Session-ID header [5] in the INVITE request. The session ID consists of 32 hexdecimal values, and it uniquely identifies a communication session end-to-end, from the originating device to the terminating device. Unlike the Call-ID header field (which may be modified by intermediate networks), the session ID remains the same throughout the session. Therefore, we can utilize the session ID in CIV as follows. In the initial call, the Session-ID header field contains a unique session ID while the Remote parameter is null (32 zeros). In the verification call, the Session-ID header field contains a different session ID while the Remote parameter contains the same session ID as in the initial call. The receiver of the verification call can therefore explicitly match the verification call with the initial call based on the session ID. The following shows examples of the relevant headers in the INVITE request.¶
Example of the selected headers in the initial SIP call:¶
To: "Bob" <sip:[email protected]>
From: "Alice" <sip:[email protected]>;tag=887s
Supported: civ
Session-ID: ab30317f1a784dc48ff824d0d3715d86;
remote=00000000000000000000000000000000
¶
Example of the selected headers in the CIV verification call (note that the last four digits of Bob's caller ID in the From header field has been modified to contain a random challenge):¶
To: "Alice" <sip:[email protected]>
From: "Bob" <sip:[email protected]>; tag=a48s
Call-Info: <sip:[email protected]>; purpose=civ-veri-call
Session-ID: 47755a9de7794ba387653f2099600ef2;
remote=ab30317f1a784dc48ff824d0d3715d86
¶
Table 1 summarizes the differences between STIR/SHAKEN and CIV. One fundamental difference is that STIR/SHAKEN authenticates the carrier, while CIV authenticates the caller ID. Technically, STIR/SHAKEN uses a digital signature and certificates, which require trusted certificate authorities in a public key infrastructure, and the transmission of kilobytes of data. By contrast, CIV only needs to transmit 4 digits, which is well supported by both IP and non-IP networks. The trade-off of CIV is that it requires a round trip to complete the challenge-and-response process between the originating and terminating carriers. This adds a round-trip delay to the caller’s waiting time, but this delay is unnoticeable to the callee. The extra delay is mostly dominated by the verification call setup, which involves not only routing the call but also, more importantly, allocating resources along the call path to prepare for the ensuing phone conversation when the call is answered. However, in CIV, the purpose of the verification call is only to transmit a short challenge, not to establish a conversation. Hence, the "civ-veri-call" value in the INVITE request serves to inform intermediate providers to only route the call without allocating resources. This makes the transmission of the challenge quicker with less consumption of network resources.¶
| STIR/SHAKEN | CIV | |
|---|---|---|
| Authentication method | Digital signature | Challenge-response |
| Authentication subject | Carrier | Caller |
| Distinguishing legitimate and illegitimate spoofing | No (left to carriers) | Yes |
| Requires trusted certificate authorities | Yes | No |
| Data transmission | Signature + certificate chain (kilobytes) | 4 DTMF digits |
| Telecom networks | IP | IP and non-IP |
| Overhead | Certificate insurance, renewal, certificate revocation list (CRL) management, real-time validation of received certificates (likely involving round-trips to check the status of certificates) | A round-trip to send and receive 4 digits for challenge-response |
This document proposes to implement CIV in the Telecom cloud by performing the challenge-response authentication process between the originating and terminating carriers (instead of between the users' phones). Assume Alice is the caller, and Bob is the callee. We first consider the cases where both the originating and the terminating carriers support CIV. Later we will discuss the compatibility modes where only one or no carrier supports CIV in Section 4.¶
In our threat model, we assume that the attacker can freely modify the caller ID when initiating a call. The modified caller ID is permitted by the originating carrier (who may add a digital signature) and can pass through subsequent networks. We assume the attacker is not able to intercept calls. We note that a powerful adversary can intercept calls through the Law Enforcement Monitoring Facility (LEMF), SIM swap, and SS7 hacking [7], but this is beyond the capability of ordinary telephone scammers behind the number spoofing attacks.¶
In this case (most common), a legitimate caller (Alice) uses the unmodified number (Alice’s number) as the caller ID. Figure 1 describes the steps of operations.¶
In this case, the caller (Alice) modifies the caller ID to another number (Alice2) she owns. Since Alice owns that number, she can configure the call forwarding function, so that the verification call sent to Alice2 is forwarded to Alice. The rest of the process is the same as in Case 1. Figure 2 summarizes the steps of operations.¶
Alice’s and Alice2’s numbers may belong to two different carriers or the same carrier. In the case of two different carriers, Alice can choose to forward only the CIV verification calls (identified by the "civ-veri-call" value in the Call-Info header). In the case of the same carrier, e.g., when a private branch exchange (PBX) is used to show a single caller ID for all outgoing calls, a solution is needed to maintain the state of outgoing calls and forward the verification call to the respective caller. This can be done by updating the PBX software or connecting PBX to a switch that maintains the states of outgoing calls and matches them with the verification calls.¶
In this case, a spoofing attacker (Eve) modifies the number to one (Alice) that he does not own. Figure 3 summarizes the steps of operations. The first three steps are the same as in Case 1 and 2. In Step 4, Alice's carrier receives the challenge from a quickly terminated verification call. However, it finds no matching record for Alice’s outgoing call and no call-forwarding configuration for forwarding the verification call. It quietly discards the challenge. In Step 5, since Bob’s carrier doesn’t receive a response, it should reject the initial call after a time-out.¶
Table 2 summarizes compatibility modes depending on whether the originating or terminating carrier supports CIV.¶
| Originating carrier | Terminating carrier | Presentation to the called user | |
|---|---|---|---|
| 1 | Supports CIV | Supports CIV | Caller ID with explicit "verified" status |
| 2 | Doesn't support CIV | Supports CIV | Caller ID with explicit "unverified" status |
| 3 | Supports CIV | Doesn't support CIV | Caller ID with implicit "unverified" status |
| 4 | Doesn't support CIV | Doesn't support CIV | Caller ID with implicit "unverified" status |
In a normal CIV operation, the terminating carrier performs the challenge-response authentication process when the initial call indicates support for CIV. However, the terminating carrier may define a security policy to allow two types of exceptions.¶
In the first exception case, the terminating carrier performs the CIV check for an incoming call even if the call does not contain the "civ" option tag (e.g., the call uses SS7 signalling instead of SIP). This is appropriate when the terminating carrier already knows through some out-of-band channels that the caller ID of the incoming call supports CIV. The following are possible scenarios.¶
In the second exception case, the terminating carrier does not perform the CIV check even when the call contains the "civ" tag. Instead, it immediately connects the call to the user as in the current telecommunication system. However, it should explicitly alert the receiver through visual or audio means that the caller ID is unverified. The following are possible scenarios.¶
In this document, we assume that calls originate from and terminate at SIP-based Telecom clouds. However, there are scenarios where the call originates from or terminates at a traditional non-IP network. In that case, the challenge-response process in CIV still works because non-IP network providers can always spoof the caller ID at their switches and send/receive DTMF. However, CIV additionally requires a mechanism to communicate support for CIV in the initial call. This is achieved in SIP by adding a "civ" tag in the Supported header. As SIP trunking is becoming a standard for connecting business phone networks, using an extended SIP INVITE header to indicate support for CIV should be sufficient for most carriers.¶
For a small number of carriers that use only SS7, it is possible to indicate support for CIV by using an out-of-band channel. For example, the originating carrier may indicate support for CIV for a phone number in their range by adding a flag in the CNAM database (if available), to which other carriers have shared access. Furthermore, the terminating carrier may have a pre-distributed CIV-enabled list, including important phone numbers that are known to support CIV.¶
In a non-IP network, we can no longer use the session ID header to explicitly match the verification call with the initial call. Instead, the matching will be done implicitly, based on the timing of receiving a verification call after the initial call, and whether the caller ID matches an expected pattern. We assume the attacker can guess the dialed number and can make a spoofed verification call that has the call line identification (CLI) as a dialed number prefix + random 4 digits. The attacker will need to make sure the spoofed verification call is made immediately after the initial call and arrives at the receiver before the genuine verification call to win the race. This is theoretically possible, but in the worst case, this will only be a Denial of Service (DoS) attack, causing the wrong challenge to be read and the challenge-response verification process to fail. The originating carrier will need to call again. This DoS attack is detectable with the call detail record (CDR) in the Telecom cloud, which further limits its impact. We note that the use of the session ID prevents this DoS attack by design since in our threat model, the attacker cannot intercept calls and hence cannot obtain other calls' session IDs. Any spoofed verification call with an invalid session ID will be discarded by the carrier at the gateway.¶
The telephone system only works because each phone call resolves to a single phone number hosted and allocated by a network operator - the range holder for that number. The range holder can identify to whom the number is allocated (which may need to be done via number resellers). It also has the power to disable the number if necessary. Scammers often use spoofed phone numbers to hide their identity and to avoid being tracked down. Widespread adoption of CIV would prevent calls using illegitimately spoofed numbers from getting through. This would force telephone scammers to use phone numbers that are allocated to them as their caller ID. Therefore they would be traceable (via the range holder) and their service could be terminated quickly.¶
A spoofing attacker will not receive the challenge but may try to guess its value. For a challenge of n random digits, the probability of guessing successfully is 1 in 10^n. A larger value of n decreases the probability exponentially but at the cost of transmitting more digits. We recommend n = 4 as a suitable trade-off, which corresponds to a success rate of 0.01% by random guessing. Consecutively failed guesses can be easily detected by the terminating carrier, and could be dealt with accordingly, e.g., by increasing the delay between calls.¶
To bypass CIV, a spoofing attacker may use a carrier that does not support CIV or set up their own SIP server that does not include the "civ" tag in the Supported header of the INVITE request. In this downgrade attack, the call will be connected to the user but the caller ID is unverified. If the terminating carrier supports CIV, it should explicitly communicate the "unverified" status to the user, e.g., through visual/audio alerts on the phone, or a pre-recorded warning when the user answers the phone. If the terminating carrier knows through some out-of-band channels that the caller ID supports CIV, it should perform the CIV check even if the "civ" tag is not present (see Section 5.1).¶
In a normal CIV operation, the verification call is transmitted between the two carriers, and is never shown to users. However, a malicious carrier may include the "civ" tag in the INVITE request and use a spoofed caller ID belonging to another carrier that does not support CIV. This is similar to Figure 3 except that Alice’s gateway does not support CIV. In this case, the verification call will be passed onto the user’s phone and shown as a "missed call" with a caller ID that may or may not be dialable. The presence of the unknown "missed call" may confuse the user and cause a nuisance. However, this attack has a limited impact. First, it happens only if Alice’s carrier does not support CIV; otherwise, the call will have been filtered at the gateway. Second, the attacker could make a "missed call" to the user directly. In that case, the attacker can set an arbitrary caller ID for the missed call, but in CIV, he has no control over the caller ID of the verification call. Without CIV, making "missed calls" with random caller IDs to a phone user is always possible. This is deterred in practice since the gain is limited and the source can be traced based on checking the call detail records (CDRs) in the Telecom cloud. With CIV, an attacker can use the terminating carrier to make "missed calls", but he loses control of the caller ID display and tracing remains possible by correlating the two related CDRs.¶
This document proposes a new options tag "civ" for the Supported header of the INVITE request, and a new value "civ-veri-call" for the Purpose parameter in the Call-Info header.¶
We thank ...¶