| Internet-Draft | CIV | May 2025 |
| Hao, et al. | Expires 2 December 2025 | [Page] |
This document defines an extension to the INVITE header of the Session Initiation Protocol (SIP) to support a Caller ID Verification (CIV) method. CIV authenticates the caller ID of an incoming call through a challenge-and-response process across both IP and non-IP networks without requiring a trusted third party or a public key infrastructure. When receiving a call with a claimed phone number, the called party holds the call and sends a quickly terminated INVITE request (like a flash call) to that number, carrying a short 4-digit challenge embedded as part of the caller ID. A genuine caller would 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 option tag, "civ", in the Supported header field of the INVITE request. This tag allows the calling party to indicate support for CIV in the initial call. Second, it adds a special value "civ-veri-call" for the Purpose parameter of the Call-Info header field. This value allows the called party to make a verification call, indicating the purpose of the call is to transmit a challenge rather than establish a phone conversation. CIV uses the standard Session-ID header in the INVITE request to allow the calling party to explicitly match the verification call with the initial call. Whilst this document focuses on IP networks, the same CIV protocol also works with non-IP networks (e.g., SS7) by including the "civ" tag, the "civ-veri-call" value and the session ID in the User-to-User Information (UUI) parameter.¶
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 2 December 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.¶
This document describes a Caller ID Verification (CIV) method based on a peer-reviewed paper published in ACM Transactions on Privacy and Security (ACM TOPS) by Wang et al. in 2023 [5]. CIV authenticates the caller ID using a challenge-response protocol, which works with both IP and non-IP networks without requiring any trusted third party or a public key infrastructure. While it is possible to implement CIV on the users' phones, this document focuses on implementing CIV on telecommunication switches in the Telecom cloud for best performance.¶
In a telecommunication system, there are three distinct authentication problems: 1) the authentication of the carrier (typically done by verifying the possession of a private key for digital signature), 2) the authentication of the caller (through verifying a password, the possession of a token, or biometrics) and 3) the authentication of the caller ID. CIV specifically addresses the third problem through verifying whether the calling party possesses (or owns) the phone number that is sent as the caller ID, whereas the identity of the caller can be traced later if needed via the range holder of that number (assuming appropriate KYC checks are in place, or the service to number can be turned off). Crucially, CIV is a decentralized method that does not require any trusted third party (or trusted certification authorities in a public key infrastructure). Such a decentralized method is useful in many practical applications where proving the possession of the caller ID is needed to prevent spoofing attacks without involving any trusted third party. In practice, CIV can be combined with other authentication techniques (e.g., carrier authentication and caller authentication) to provide enhanced security. As an example, some banks use a system called Voice ID (or "my voice is my password") to authenticate the caller based on analyzing their voice biometrics in telephone banking, but AI-generated voices pose a real threat to defeat this caller authentication method completely [9]. Using CIV would force the attacker to call from the victim's phone (or to prove the ownership of the phone number that is registered with the bank), hence making the AI spoofing attack more difficult. Some mobile payment systems, such as Unified Payment Interface (UPI), use the mobile phone number as the unique identity to facilitate payments between users. Verifying the ownership of the phone number is an important step to prevent fraud.¶
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 [2] [3] 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 [8]. This call-back method ensures that the receiver talks to the genuine caller who possesses (or 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 across heterogeneous networks 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 possession of that number. Accordingly, it distinguishes legitimate and illegitimate modifications of the caller ID based on whether the caller possesses the number. Suppose the caller uses an unmodified number or a legitimately modified number they own. In both cases, they should receive a challenge from a call-back and hence should be able to 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.¶
In the second step of CIV, the called party holds the call before starting the challenge-response verification process. The time it takes for the verification process to finish will need to be set as a grace period, as the user has not actually answered the call while the verification of the caller ID is in process. With the current design of CIV, we expect the verification time to be mostly determined by the transmission of 4 DTMF digits (typically 0.5 seconds). If required, this grace period can be excluded from the calling party's call time in billing.¶
The verification call needs to be matched with the initial call. This can be done explicitly based on the Session-ID header [4] in the INVITE request. The session ID consists of 32 hexadecimal values. 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:+1234567222@example.com>
From: "Alice" <sip:+1415555111@example.com>;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 have been modified to contain a random challenge):¶
To: "Alice" <sip:+1415555111@example.com>
From: "Bob" <sip:+1234569685@example.com>; tag=a48s
Call-Info: <sip:+1415555111@example.com>; purpose=civ-veri-call
Session-ID: 47755a9de7794ba387653f2099600ef2;
remote=ab30317f1a784dc48ff824d0d3715d86
¶
This document proposes to implement CIV in the Telecom cloud by performing the challenge-response authentication process between switches of 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 [6], but this is beyond the capability of ordinary telephone scammers behind the number spoofing attacks.¶
When the INVITE request contains the "civ" option tag in the Supported header field, this indicates that the calling party is willing to support the CIV check of the presented caller ID. For such a call, the originating carrier shall keep a CIV call state, containing at least the following information: {caller, callee, call time, session ID}, where "caller" represents the caller's number (which may be the caller ID or an internal number in a PBX system), "callee" represents the callee's number, "call time" indicates the time when the initial call is made, and "session ID" is the value contained in the Session-ID header field. The following is an example.¶
| Caller | Callee | Call time | Session ID |
|---|---|---|---|
| 1234567222 | 1415555111 | 2024-02-27 15:35:20.311 | ab30317f1a784dc48ff824d0d3715d86 |
In this example, the call time is represented in the "yyyy-MM-dd HH:mm:ss.SSS" format. Alternatively, it may be represented using a 13-digit epoch time, i.e., the number of milliseconds since January 1, 1970.¶
The CIV call state is transient data, kept during the call setup phase only. The originating carrier writes a record of the state when making the initial call containing the "civ" tag, and deletes the record immediately after the call is connected or has failed (e.g., after a timeout).¶
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.¶
The called party, Bob, may have a call-forwarding setting. When the call is forwarded to a voicemail, this is treated the same as being answered by a user; the CIV operation is not affected. When the call is forwarded to another number, CIV works as follows.¶
In general, there are two ways to forward a call.¶
In proxy-based call forwarding, a single incoming SIP call may be simultaneously forwarded to multiple devices or extensions. For example, a call to a user's number can make the user's desk phone and the SIP softphone on his mobile ring at the same time. That is called SIP forking. We call a phone number "local" if it belongs to the same terminating carrier, and "remote" if it belongs to a different carrier. In general, within the same carrier, if the caller ID of an incoming call has been verified, the verified status is transferable within the trusted domain of the same carrier. In that case, there is no need for the carrier to perform the CIV check for this call again. However, when the call is forwarded to a remote number, the next carrier will want to check the caller ID (assuming that the previously verified status of the caller ID is not transferable to the next carrier). We consider how CIV works in the following SIP forking scenarios (see Figure 4).¶
In this case, the caller (Alice) modifies the caller ID to another number (Alice2) she owns. CIV distinguishes legitimate and illegitimate spoofing of a phone number based on whether the caller owns that number. Therefore, if Alice owns Alice2's 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 5 summarizes the steps of operations.¶
Alice’s and Alice2’s numbers may belong to the same carrier, e.g., when a private branch exchange (PBX) is used to show a single caller ID for all outgoing calls. In this case, a solution is needed to maintain the state of outgoing calls and forward the received challenge to the correct 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.¶
Alice’s and Alice2’s numbers may belong to two different carriers. In this case, Alice can choose to forward only the CIV verification call (identified by the "civ-veri-call" value in the Call-Info header) sent to Alice2's number. However, in a distributed telephone network, where to forward the call may not always be obvious. The following is an example.¶
A large enterprise typically has multiple call centres that are distributed over distant geographic locations with limited or no communication between them. Calls from the enterprise commonly present a caller ID that reaches a main receptionist or could be answered by any member of a call centre. A call-back to that number may not go to the same call centre that originated the call. For CIV to work, the verification call will need to be forwarded to the system that keeps the state of outbound call setup attempts. There are two solutions to support legitimate spoofing of the caller ID in this distributed network setting.¶
In this case, a spoofing attacker (Eve) modifies the number to one (Alice) that he does not own. Figure 8 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 after a time-out, it concludes that the verification has failed. Depending on the carrier and the user-defined configurations, the terminating carrier may reject the call, connect it to the user's phone with an explicit visual/audio warning about the invalidated caller ID, send the call directly to voicemail, or take other actions.¶
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 contains a "civ" tag that indicates support for CIV. However, the terminating carrier may define a security policy to exempt the CIV check and immediately connect the call to the user. The following are possible scenarios.¶
In this document, we assume that both the originating and the terminating carriers support SIP and use standard SIP trunking for connecting with other phone networks. Typically, a SIP call traverses IP networks. However, sometimes the call path may contain a non-IP segment (e.g., PSTN, SS7), which allows limited data transmission. CIV is designed to carry only the minimum amount of data required for caller ID authentication. The data involved in each of the three CIV steps is explained below.¶
To make CIV work reliably across heterogeneous networks, we should ensure the CIV data is not lost along the call path. When traversing a non-IP segment, we recommend using the User-to-User Information (UUI) parameter in SS7 to carry the CIV data during the IP to non-IP network conversion, and restore the same CIV data during the non-IP to IP network conversion. Normally, the data size limit of UUI is 128 bytes, as specified in ITU-T Q.763 (or 131 bytes in ANSI) in the payload. This is more than sufficient to store the small amount of CIV data in the initial call (17 bytes) and in the verification call (33 bytes). Details of the encoding of the CIV data in UUI and the conversion between IP and non-IP networks are outside the scope of this document.¶
In the rare case when the originating or terminating carrier does not use SIP trunking and only uses legacy SS7 for connecting with other networks, they can still support CIV at the switch level by carrying the CIV data in the UUI parameter. The CIV protocol works across heterogeneous networks by converting data in the UUI parameter to the SIP INVITE header, and vice versa.¶
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 remains unverified. The terminating carrier can 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. In some applications (e.g., telephone banking), the system may restrict the caller from performing certain security operations during a call if the caller ID is not verified.¶
CIV uses a quickly terminated flash call to transmit a challenge. 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. One might be concerned that the verification call would reach a target user's phone as a "missed call" (with a caller ID that may or may not be dialable). The presence of such a "missed call", especially when it makes the phone ring momentarily, can be a nuisance to the user. This could be regarded as a Denial of Service (DoS) attack. Note that the attacker can always make "missed calls" to the user directly, e.g., in Wangiri scams. Unlike a Wangiri call, in CIV, the attacker cannot control the caller ID of the reflected verification call. Hence, the impact of the attack is more limited. Here, instead of attacking the user directly, the attacker uses a carrier to launch a reflected DoS attack.¶
The reflected DoS attack can be easily prevented as follows. First, if the carrier that receives the verification call supports CIV, it will discard the call by design based on checking it against the state of outgoing calls. Second, if the carrier does not support CIV, it can stop this attack by simply filtering incoming calls containing the "civ-veri-call" value. Third, in 4G and 5G networks, voice services run over IMS (IP Multimedia Subsystems) and that stack uses SIP end-to-end, including on the user equipment. Therefore, the user's device can detect the "civ-veri-call" value and block the verification call (which should not reach the user's phone in the first place), hence providing a further layer of defence on the phone. This solution works with modern mobile phones (4G and onwards) and SIP-based desk phones, although it does not work with legacy GSM/3G and landline phones.¶
This document defines a new option tag "civ" for the Supported header of an INVITE request in the "Option Tags" registry as below.¶
This document also defines a "civ-veri-call" value for the Purpose parameter in the Call-Info header of an INVITE request as below. This value, paired with the same URI as in the TO header, indicates that the purpose of the current INVITE is to make a verification call.¶
We thank ...¶