RFC 7340
Secure Telephone Identity Problem Statement and Requirements
RFC 7340: Secure Telephone Identity Problem Statement and Requirements 📞✨
- Series: Internet Engineering Task Force (IETF), Request for Comments 7340
- Authors: J. Peterson (NeuStar, Inc.), H. Schulzrinne (Columbia University), and H. Tschofenig
- Category: Informational
- ISSN: 2070-1721
- Date: September 2014
- Obsoletes or updates: nothing. This RFC doesn't replace or update any earlier RFC. 🫶
Abstract 💖
Okay so, over the past decade, Voice over IP (VoIP) systems based on SIP have basically replaced a ton of traditional phone setups 📱. But linking VoIP with the old-school telephone network has made calling party number and Caller ID assurances way weaker 😭. That gives attackers cheap, easy tools to impersonate or hide who's calling 🙈. They use them for bulk commercial calling schemes, hacking voicemail boxes, and even getting around multi-factor authentication systems that banks trust 💀.
Even with earlier attempts to securely prove where SIP communications come from, we still don't have effective standards for identifying the calling party in a VoIP session. This document looks at why giving telephone numbers an identity on the Internet has been so hard 🧐. It also shows how changes over the last decade could open up new strategies for attaching a secure identity to SIP sessions 🦋. Last but not least, it gives high-level requirements for a solution in this space 🎀.
Status of This Memo 🌸
This document is not an Internet Standards Track specification. It's published for informational purposes.
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). Not every document the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for that.
For info on the current status of this document, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc7340 🔍.
Copyright Notice 🔒
Copyright (c) 2014 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 (http://trustee.ietf.org/license-info) as they apply on the publication date of this document. Please read these documents carefully, because they explain your rights and restrictions regarding 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 they come without warranty as described in the Simplified BSD License 📜.
Table of Contents 🧚
1. Introduction ....................................................3
2. Problem Statement ...............................................4
3. Terminology .....................................................6
4. Use Cases .......................................................6
4.1. VoIP-to-VoIP Call ..........................................7
4.2. VoIP-PSTN-VoIP Call ........................................7
4.3. PSTN-to-VoIP Call ..........................................8
4.4. VoIP-to-PSTN Call ..........................................9
4.5. PSTN-VoIP-PSTN Call .......................................10
4.6. PSTN-to-PSTN Call .........................................11
5. Limitations of Current Solutions ...............................11
5.1. P-Asserted-Identity .......................................12
5.2. SIP Identity ..............................................14
5.3. VIPR ......................................................17
6. Environmental Changes ..........................................19
6.1. Shift to Mobile Communication .............................19
6.2. Failure of Public ENUM ....................................19
6.3. Public Key Infrastructure Developments ....................20
6.4. Prevalence of B2BUA Deployments ...........................20
6.5. Stickiness of Deployed Infrastructure .....................20
6.6. Concerns about Pervasive Monitoring .......................21
6.7. Relationship with Number Assignment and Management ........21
7. Basic Requirements .............................................22
8. Acknowledgments ................................................23
9. Security Considerations ........................................23
10. Informative References ........................................231. Introduction ✨
Okay, bestie, so in lots of communication setups where users talk to other users, you need to figure out who's starting the call or the messaging session 📞💅. Knowing who's on each end matters for end-to-end communication because it lets you enforce authorization policies, like deciding whether to accept or reject a call attempt. It's also been used for charging 💸. There are a bunch of ways to do identification, and the Session Initiation Protocol (SIP) [RFC3261] handles it with two main approaches: P-Asserted-Identity (PAI) [RFC3325] and SIP Identity [RFC4474]. We'll get into those more in Section 5 🧠. The whole goal of these mechanisms is to check that the person originating a call is actually allowed to claim the identifier they're using 🔐. Protocols like the Extensible Messaging and Presence Protocol (XMPP) use ideas that are conceptually similar to what SIP does 🫶.
Here's the tea ☕: even though these solutions were standardized, the current deployment situation is pretty unsatisfying 😩. Honestly, there's little sign that it'll get better anytime soon 💀. In [SECURE-ORIGIN], we lay out what challenges show up. The big issue is that interworking with other communication architectures (for example, SIP, Public Switched Telephone Network (PSTN), XMPP, and Real-Time Communications on the Web (RTCWeb)), or other forms of mediation, breaks the end-to-end semantics of the interaction and wipes out any identification capabilities 🙅♀️. (Quick note: in this document, we use the term "PSTN" casually, not in a legal or policy sense. It's just shorthand for the circuit-switched analog and time-division multiplexing (TDM) digital telephone system, which often uses Signaling System #7 (SS7) to set up and tear down calls 📼.) On top of that, using different identifiers (like E.164 numbers vs. SIP URIs) makes it hard to figure out who's allowed to claim "ownership" of a specific identifier 🤷♀️. Domain-based identifiers like sip:user@example.com can use certificate or DNS-related approaches to determine who owns the URI, but telephone numbers don't have any similar mechanism defined yet 📵.
After the PAI and SIP Identity specifications ([RFC3325] and [RFC4474], respectively) came out, people tried again to tackle this topic. Unfortunately, it didn't go super well 😭. Deploying solutions is complicated, and there's a long list of requirements that often conflict with each other 🌀. It's been a few years since anyone seriously tried to improve things, so we think it's time to give it another go 🚀. With this document, we want to build a shared understanding of the problem statement and the basic requirements. That way we can work out a vision for moving the state of the art forward and kick off the technical work needed to enable secure call origin identification 🌈💜.
2. Problem Statement ✨
okay so bestie, picture the old-school phone network, the Public Switched Telephone Network (PSTN) 📞. There were only a few carriers, and they all just trusted each other to pass along who was calling. Nobody was doing any cryptographic checking 🔐. Some countries even wrote those duties into law 📜. It worked fine as long as the number of players stayed small, you could easily tell who was who (like how carriers get certified in the US), and there were real legal consequences if someone misbehaved ⚖️.
But those assumptions are no longer true, and it's giving chaos 💀. Entities that aren't traditional carriers can act as voice service providers, and they might be sitting outside the country whose country code they're using 🌍. Back in the day, customers and service providers were clearly different people, but VoIP providers can now be customers, or originating or transit providers, all at once 🙃. And it's not just voice either. Text messaging has become another way for spammers to send bulk unsolicited commercial messages by impersonating a source telephone number or, sometimes, an SMS short code 📱. Caller ID spoofing is everywhere now 😭, with a small group of entities either ignoring the abuse happening on their services or actively helping with fraud and other illegal stuff 🚨.
Here's a real mess. Enterprises and public safety organizations have been hit with telephony denial-of-service attacks [TDOS] 😤. A so-called collections company for payday loans calls an organization to start an extortion scheme. If the target doesn't pay up, the criminals unleash a barrage of calls from spoofed numbers, so the organization can't receive any legitimate calls at all 📵. Other boiler-room operations use number spoofing to make illegal "robocalls" (automated telemarketing; see, for example, the US Federal Communications Commission webpage on this topic [ROBOCALL-FCC]) 🤖. Regulators have noticed this too. For example, the US Federal Trade Commission (FTC) recently ran a robocall competition to find ways to block illegal robocalls [ROBOCALL-CHALLENGE] 🏆. And criminals can also spoof numbers to pretend to be banks or bank customers and get into information or financial accounts 🏦.
So basically, number spoofing gets used in two main ways: impersonation and anonymization 🎭.
With impersonation, the attacker pretends to be one specific person. That can be used for pretexting, where the attacker learns about the person they're pretending to be and then, for example, activates credit cards 💳. It can also be used for harassment, like getting utility services disconnected, having take-out food delivered, or getting police to respond to a hostage situation that doesn't exist ("swatting"; see [SWATTING]) 🚓. Some voicemail systems grant access to stored messages with no password at all, relying only on the caller's identity 📼. Remember the News International phone-hacking scandal [NEWS-HACK]? Newspaper employees were accused of phone hacking by using Caller ID spoofing to get into voicemail 😬. And when a caller has hidden their textual caller identification, spoofing a number can be used to pull that info from the so-called Calling Name (CNAM) database 🗂️.
With anonymization, the caller doesn't really care whether the number is in service or who it belongs to, and they might switch numbers rapidly, maybe even randomly 🎲. This makes automated illegal telemarketing or telephony denial-of-service attacks easier, as described above, because it's hard to identify the bad actors and build policies to block them 🙅♀️. Tracing these calls is also a huge pain 😩, since each call has to be identified at every transit carrier hop-by-hop, based on the destination number and the time of the call 🕵️♀️.
Simply outlawing all spoofing of originating telephone numbers isn't enough, bestie 🙄. The entities spoofing numbers are already committing other crimes, so legal sanctions probably won't scare them off 🚫. Secure origin identification should stop impersonation and, to a lesser extent, anonymization 🛡️. But if numbers are easy and cheap to get, and the organizations assigning identifiers can't or won't verify the true corporate or individual identity of whoever is requesting them, robocallers will still be able to hop between tons of different identities 🐇.
Things get even more complicated because there are plenty of legitimate cases where entities in the telephone network send calls on behalf of others, including "Find-Me/Follow-Me" services 📲. Ultimately, any SIP entity can receive an INVITE request and forward it to any other entity, and the recipient of a forwarded message has little way to check which recipient the call should actually be aimed at (see [SIP-SECURITY]) 🤷♀️. Sometimes, third parties also need to temporarily use the identity of another person or organization, with the full consent of the "owner" of the identifier 🤝. For example:
- Doctors' offices: Physicians calling their patients from their cell phones want to swap their mobile number for their office number, so patients don't call them back on their personal phones 🩺💖.
- Call centers: Call centers operate on behalf of companies, and the person being called expects to see the company's Caller ID, not the call center's 🎧✨.
3. Terminology 🎀
okay, so this document defines the following terms, and they're kind of the vocab you need to know 📚:
In-band Identity Conveyance: In-band conveyance means the call origin identification information is carried inside the control plane protocol(s) that set up the call 📨. Any in-band solution has to play nice with in-band intermediaries like Back-to-Back User Agents (B2BUAs) 🤝.
Out-of-Band Identity Verification: Out-of-band verification checks whether the telephone number the caller is using actually exists, whether the calling entity is allowed to use that number, and whether a call was recently made from that number 🔍. This approach is needed because the in-band technique doesn't work in every case, like when certain intermediaries are involved or when there's interworking with circuit-switched networks 🔀.
Authority Delegation Infrastructure: The delegation authority infrastructure decides how authority over telephone numbers is used when numbers get ported and delegated 🔁. It also describes how the existing numbering infrastructure gets reused to manage the lifecycle of number assignments ♻️.
Canonical Telephone Number: For either in-band conveyance or out-of-band verification to work, entities have to be able to canonicalize telephone numbers so they all end up in one common syntactical form 🧩.
4. Use Cases 🦋
okay, so to explain the requirements and the other design assumptions, we're going to walk through some scenarios that any solution needs to support 💅. To keep things less cluttered, the figures don't show call-routing elements like SIP proxies of voice or text service providers 🙈. We generally assume that the PSTN part of any call path can't be altered 🔒.
4.1. VoIP-to-VoIP Call 💜
So for the VoIP-to-VoIP case, a group of service providers offering interconnected VoIP service exchange calls end-to-end using SIP 📡. They might also deliver some calls over circuit-switched facilities, which get covered in the separate use cases below 🔌. These providers use telephone numbers as source and destination identifiers, either as the user component of a SIP URI (e.g., sip:12125551234@example.com) or as a tel URI [RFC3966] 🔢.
As Figure 1 shows, if Alice calls Bob, the call uses SIP end-to-end. (The call may or may not traverse the Internet 🌐.)
+------------+
| IP-based |
| SIP Phone |<--+
| of Bob | |
|+19175551234| |
+------------+ |
|
+------------+ |
| IP-based | |
| SIP Phone | ------------
| of Alice | / | \
|+12121234567| // | \\
+------------+ // ,' \\\
| /// / -----
| //// ,' \\\\
| / ,' \
| | ,' |
+---->|......: IP-based |
| Network |
\ /
\\\\ ////
-------------------------
Figure 1: VoIP-to-VoIP Call4.2. VoIP-PSTN-VoIP Call 📞
Pretty often, two VoIP-based service providers aren't directly connected by VoIP, so they use Time Division Multiplexer (TDM) circuits to exchange calls 🔁. That's the IP-PSTN-IP use case 💫. In this one, Dan's Voice Service Provider (VSP) isn't a member of the interconnect federation that Alice's and Bob's VSP belongs to 🚧. From Alice's point of view, Dan isn't reachable over IP, so the PSTN acts as the interconnection network 🌉. Figure 2 shows how the exchange works 👇.
--------
//// \\\\
+--- >| PSTN |
| | |
| \\\\ ////
| --------
| |
| |
| |
+------------+ +--+----+ |
| IP-based | | PSTN | |
| SIP Phone | --+ VoIP +- v
| of Alice | / | GW | \ +---+---+
|+12121234567| // `''''''' \\| PSTN |
+------------+ // | \+ VoIP +
| /// | | GW |\
| //// | `'''''''\\ +------------+
| / | | \ | IP-based |
| | | | | | Phone |
+---->|---------------+ +------|---->| of Dan |
| | |+12039994321|
\ IP-based / +------------+
\\\\ Network ////
-------------------------
Figure 2: IP-PSTN-IP CallNote: A B2BUA/Session Border Controller (SBC) acts a lot like this scenario, since in the worst case the original call content would be re-created on the call origination side 🫶.
4.3. PSTN-to-VoIP Call ✨
Okay, picture this: Carl is on a regular old PSTN phone 📞 and he's calling Alice, who's on a VoIP phone 💻. His call goes through the PSTN first, then hops onto the Internet at a PSTN/VoIP gateway 🌉. That gateway also tags the call with some identity info, based on the caller ID it got from the PSTN, if there was any 🎀.
--------
//// \\\\
+->| PSTN |--+
| | | |
| \\\\ //// |
| -------- |
| |
| v
| +----+-------+
+---+------+ |PSTN / VoIP | +-----+
|PSTN Phone| |Gateway | |SIP |
|of Carl | +----+-------+ |UA |
+----------+ | |Alice|
INVITE +-----+
| ^
V |
+---------------+ INVITE
|VoIP | |
|Interconnection| INVITE +-------+
|Provider(s) |----------->+ |
+---------------+ |Alice's|
|VSP |
| |
+-------+
Figure 3: PSTN-to-VoIP Call4.4. VoIP-to-PSTN Call 📱➡️☎️
Next up, Figure 4 🔮. This time Alice is the one calling Carl, who's on a PSTN phone, and Alice is on an IP-based phone. When Alice starts the call, the E.164 number gets translated into a SIP URI, and then into an IP address 🪄. Her call goes through her VoIP provider, which adds the call origin identification info, and then it hits the PSTN/VoIP gateway. It's desirable that the gateway checks that Alice is actually allowed to claim the E.164 number she's using before it fills in the calling party number field in the telephone network signaling. Carl's phone also needs to be able to verify that the call is legit, coming from the calling party number it's going to show him 🕵️♀️. Honestly, the verification part is so important, no cap 💅.
+-------+ +-----+ -C
|PSTN | |SIP | |a
|Phone |<----------------+ |UA | |l
|of Carl| | |Alice| |l
+-------+ | +-----+ |i
--------------------------- | |n
//// \\\\ | |g
| PSTN | INVITE |
| | | |P
\\\\ //// | |a
--------------------------- | |r
^ | |t
| v |y
+------------+ +--------+|
|PSTN / VoIP |<--INVITE----|VoIP ||D
|Gateway | |Service ||o
+------------+ |Provider||m
|of Alice||a
+--------+|i
-n
Figure 4: VoIP-to-PSTN Call4.5. PSTN-VoIP-PSTN Call 🦋
Now Figure 5 is giving full sandwich energy 🥪. Carl calls Alice, and they both have PSTN phones 📞📞. The catch is that the two circuit-switched parts of the PSTN are connected through an IP network, so Carl's operator uses a PSTN-to-VoIP gateway to send the call over IP to another gateway, which breaks out into the PSTN again 🌈.
+----------+
|PSTN Phone|
-------- |of Alice |
//// \\\\ +----------+
+->| PSTN |------+ ^
| | | | |
| \\\\ //// | |
| -------- | --------
| v //// \\\\
| ,-------+ | PSTN |
| |PSTN | | |
+---+------+ __|VoIP GW|_ \\\\ ////
|PSTN Phone| / '`''''''' \ --------
|of Carl | // | \\ ^
+----------+ // | \\\ |
/// -. INVITE ----- |
//// `-. \\\\ |
/ `.. \ |
| IP-based `._ ,--+----+
| Network `.....>|VoIP |
| |PSTN GW|
\ '`'''''''
\\\\ ////
-------------------------
Figure 5: PSTN-VoIP-PSTN Call4.6. PSTN-to-PSTN Call 🫶
For the "legacy" PSTN-to-PSTN case, the one that's otherwise beyond improvement 🙈, we may be able to use out-of-band IP connectivity at both the originating and terminating carrier to validate the call information. Iykyk 💜.
5. Limitations of Current Solutions 🚧
Okay, real talk, this section is where things get messy 😭. Ever since SIP was born, the From header field value has held an arbitrary user-supplied identity, kinda like the From header field in an SMTP email 📧. While [RFC3261] was being worked on, people started trying to give SIP requests a secure origin as an extension to SIP 🔐. The so-called "short term" fix is the P-Asserted-Identity header described in [RFC3325], and it's deployed pretty widely 💅. The catch? It only works on closed trusted networks, where end-user devices can't change or inspect SIP messages, and it offers no cryptographic validation 💀. As P-Asserted-Identity gets used across more and more networks, it can't protect against identity spoofing by intermediaries, or by entities that let untrusted parties set the P-Asserted-Identity info 🙅♀️. If you want an overview of spam in SIP and how it's different from similar email problems, check out [RFC5039] 📚.
Then came more efforts to stop calling-origin identity spoofing in SIP: the SIP Identity effort (the "long-term" identity solution) [RFC4474], and Verification Involving PSTN Reachability (VIPR) [VIPR-OVERVIEW] 🌸. SIP Identity attaches a new header field to SIP requests, containing a signature over the From header field value plus other message components, to prevent replay attacks 🔏. It's meant to stop both (a) SIP UAs from starting calls with spoofed From headers, and (b) intermediaries like SIP proxies from doing man-in-the-middle attacks by altering calls as they pass through 👀. VIPR went even bigger, tackling a broader set of problems around spam, routing, and identity with a brand new infrastructure for managing rendezvous and security, which ran alongside SIP deployments 🧚.
As we'll dig into below, both SIP Identity and VIPR have serious limitations that stopped them from being deployed at a big scale 😩, but they might still have useful ideas and protocol building blocks for a solution ✨.
5.1. P-Asserted-Identity 💖
Okay bestie, so the P-Asserted-Identity header field from SIP [RFC3325] is how trusted network entities pass around an authoritative identifier for whoever started a call 📞✨ Users can't fill it in themselves. If a user wants to suggest an identity to the trusted network, they use a separate header called P-Preferred-Identity 🎀 This whole feature grew out of an effort to match what traditional telephone signaling can do: sharing or hiding the calling party number at the user level, while core network elements still know who the user is for abuse prevention and accounting 🛡️💅
To make P-Asserted-Identity work like that, it needs a trust domain, as described in [RFC3324] 🌸 Any entity inside the trust domain can add a P-Asserted-Identity header to a SIP message, and any entity in the trust domain can forward a message carrying one to any other entity in the trust domain 🦋 But if a trusted entity forwards a SIP request to an untrusted entity, the P-Asserted-Identity header must first be removed first, because most end-user devices live outside trust domains 🙈 Sending it to an untrusted entity could leak private info, like the network-asserted calling party number when the caller asked for presentation restriction 😭 The idea of a trust domain is modeled on the trusted network of devices that run the traditional telephone network, so it's very on-brand for telco 📠✨
P-Asserted-Identity has been a huge hit in telephone replacement deployments of SIP 👑 It's an extremely simple in-band mechanism and doesn't need any cryptographic operations 🧚 Because it feels so familiar from the old telephone network and interworks so smoothly with those protocols, providers who are comfy with those operating principles have naturally gravitated toward it 💜
Real talk though, a trust domain has the same pros and cons as the traditional telephone network when it comes to securing a calling party number 💀 Any trusted entity can provide P-Asserted-Identity, and a recipient of a SIP message has no direct assurance of who generated the header field value. Trust is transitive, full stop 🫠 Trust domains are set by business arrangements more than by security standards, so the level of assurance for P-Asserted-Identity is only as good as the least trustworthy member of the trust domain 🥀 The contents aren't meant for end users to look at, so end users have to trust that their service provider is part of an appropriate trust domain, since there's no direct evidence of the trust domain in the SIP signaling their devices receive 🙃 Since it's so closely modeled on the traditional telephone network, it's unlikely to be any more secure than that 🔐
Also, since [RFC3325] was written, the whole idea of "P-" headers meant for private SIP domains has been deprecated (see [RFC5727]) 🪦 The main reason is overwhelming evidence that these headers were leaking out of private contexts and onto the public Internet 🌐😱 It's unclear how many deployments using P-Asserted-Identity actually conform to the Spec(T) requirements of [RFC3324] 🤷♀️
P-Asserted-Identity also makes it harder to decide which URI should be shown to a user when a call comes in 📱 Per [RFC3261], SIP user agents render the contents of the From header field to the user when they receive an INVITE request. But what if P-Asserted-Identity carries a more trustworthy URI and presentation isn't restricted? 🤔 People have also proposed additional header fields to carry different forms of caller identity, including billing identities 💸 As the calling identities in a SIP request keep multiplying, figuring out which one to show the end user gets way harder to answer, and honestly that's giving main character chaos 🌈🎭
5.2. SIP Identity ✨
okay so the SIP Identity mechanism [RFC4474] gives you two header fields for locking down identity info in SIP requests: Identity and Identity-Info 🔐. The big picture is the classic "SIP trapezoid" setup 💅. An authentication service, working on behalf of whoever sent the request, attaches identity info to it, which gives partial integrity protection. Then a verification service, working for the recipient, checks the integrity when the request shows up 🦋.
The Identity value is a signature over a hash of selected bits of the request. That includes several header field values (most importantly the From one) plus the entire body 🎀. Those header values were picked super carefully to stop cut-and-paste attacks, but it means the verification service has to keep some state so it can guard against replays 🧠. The body signature behaves differently for different SIP methods, but they all stop man-in-the-middle attacks from tampering 🛡️. For a SIP MESSAGE request, the body signature covers the actual message being sent. Honestly it's pointless to prove who sent something if a man in the middle can swap out the content, because then the content was made by an attacker 😭. Similar threats exist against the SIP NOTIFY method 👀. For a SIP INVITE, the signature over the Session Description Protocol (SDP) body is meant to stop a man in the middle from changing the media stream stuff, like the IP address and port the media should go to 🎧. Otherwise they could send the media to somewhere the originator never picked and pretend to be the intended listener. Main character villain behavior, not it 💀.
The Identity-Info value is a URI pointing to the certificate for the private key that signed the hash in Identity 🗝️. That cert could travel by-value right alongside the request, in which case a cid URI shows up in Identity-Info. Or it could be by-reference, like when Identity-Info has the URL of a service that delivers the cert 🌐. [RFC4474] also adds rules about the cert's subject: it must cover the domain name in the domain component of the URI in the From header field value of the request 📜.
Now the tea ☕. The SIP Identity mechanism has two fundamental limitations that basically kept it from getting deployed 😩. First, it only gives you identity for domain names, not other kinds of identifiers. Second, it doesn't tolerate intermediaries that alter the bodies or certain header fields of SIP requests. Literally a dealbreaker 🙈.
Here's the thing: SIP mostly copies the structure of the telephone network, so it uses telephone numbers as identifiers 📞. A telephone number in the From header field value of a SIP request might show up as the user part of a SIP URI, or as an independent tel URI 🌸. But the cert that Identity-Info points to, as specified, only corresponds to the domain portion of the SIP URI in From. So [RFC4474] has no provision for identifying the assignee of a telephone number 🤷♀️. Sure, the domain part could be a carrier, like "att.com", that numbers get assigned to. But the SIP Identity mechanism gives zero assurance that a particular number was assigned to any specific carrier 🚫. And for a tel URI, it's unclear in [RFC4474] which entity is supposed to hold the matching cert 🫠. A caller might not want to reveal its service provider to the callee, so it might prefer tel URIs in From 🕵️♀️.
This lack of authority gives birth to a whole class of SIP Identity problems when telephone numbers are involved, which [CONCERNS] digs into 🍓. That document shows how the Identity header of a SIP request aimed at a telephone number (embedded in a SIP URI) could get dropped by an intermediate domain. That domain then modifies and re-signs the request, and the verification service never finds out 😱. It literally has no way of knowing which original domain signed it. As long as the local authentication service is complicit, an originator can claim virtually any telephone number and impersonate any Caller ID it likes, from the verifier's point of view 💀. Both of these attacks come down to the verification service being unable to pin down a specific cert that's authoritative for a telephone number 🔥.
And SIP is highly mediated, in ways [RFC3261] didn't see coming 🧚. Request routing usually depends on policies that are dissimilar to [RFC3263], so requests bounce through multiple intermediate domains to reach a destination 🚏. Some kinds of intermediaries in those domains can effectively reinitiate the session 🔁.
One of the main reasons SIP deployments copy the PSTN architecture is that interconnection with the PSTN is still non-negotiable 👑. A call might start in SIP and end on the PSTN, or the other way around. Even worse, a PSTN-to-PSTN call might transit a SIP network in the middle, or vice versa 🌀. That basically shrinks SIP's feature set down to the least common denominator of the telephone network, and forces it to support telephone numbers as the primary calling identifier 📱.
Interworking with non-SIP networks makes end-to-end identity really messy 😵💫. When a PSTN gateway sends a call to a SIP network, it creates the INVITE request from scratch, even if an earlier leg of the call started in a SIP network that later handed the call off to the PSTN 🔄. Those gateways aren't necessarily run by anyone who has any relationship to the number's assignee, so it's unclear how they could provide an identity signature that a verifier should trust 🤔. Also, how could the gateway even know that the calling party number it gets from the PSTN is authentic? And when a gateway receives a call over SIP and terminates it to the PSTN, how can it verify that the telephone number in the From header field value is authentic before presenting it as the calling party number on the PSTN? Big "iykyk" energy 🙃.
Similarly, some SIP networks deploy intermediaries that act as back-to-back user agents (B2BUAs) 🎭. They usually do this to provide policy or interworking functions at network boundaries, which is where the nickname "Session Border Controller" comes from 🏰. Those functions range from topology hiding, to alterations needed to interoperate with particular SIP implementations, to simple network address translation from private address space 🧩. To do all this, these entities modify SIP INVITE requests in transit. They can change the From, Contact, and Call-ID header field values, plus aspects of the SDP, especially the IP addresses and ports associated with media 🎶. So a SIP request leaving a B2BUA doesn't necessarily look much like the original request the B2BUA received. It's kind of like how an SS7 request leaving a PSTN gateway can transform every aspect of the SIP request in the VoIP leg of the call ✨. An Identity signature made for the original INVITE has no bearing on the post-B2BUA INVITE. And if the B2BUA kept the original Identity header, any verification service would catch a violation of the integrity protection 🚨.
The SIP community has known about these problems with [RFC4474] in real deployments for a long time 🫶. Some people have proposed weakening the security constraints of [RFC4474] so that at least some B2BUA deployments can work with integrity protection of SIP requests 🧃. But those solutions don't fix the key problems from above: there's no clear authority for telephone numbers, and some INVITE requests get generated by intermediaries instead of endpoints 🙅♀️. Removing the signature over the SDP from the Identity header won't, for example, make it any clearer how a PSTN gateway should assert identity in an INVITE request 💖.
5.3. VIPR 💅
Okay bestie, let's talk about Verification Involving PSTN Reachability (VIPR) 🦋. It goes straight for the twin problems of figuring out who actually owns a number on the Internet and dealing with middleman boxes that might mess with signaling. For the first problem, VIPR just uses the PSTN itself 📞. It finds out which Internet endpoints are reachable through a given PSTN number by calling that number and checking who picks up. As VIPR-enabled endpoints tied to PSTN numbers get discovered, VIPR sets up a rendezvous service so the endpoints of a call can make an out-of-band connection over the Internet 🌸. That connection lets them swap info that secures future communications and allows direct, unmediated SIP connections. Iconic, honestly ✨.
VIPR keeps its powers in a pretty narrow lane though 🎀. Its seminal use case is the enterprise IP Private Branch Exchange (IPBX), which is a device with both PSTN and Internet connectivity and serves a bunch of local users with telephone numbers. So here's the flow: a PSTN call connects successfully and then ends, and then the PBX searches a distributed hash table to see if any VIPR-compatible devices have advertised themselves as a route for that unfamiliar number on the Internet 🔍. If there are advertisements, the originating PBX starts a verification process to check whether the entity claiming to be the assignee of that unfamiliar number actually got the successful call. That means verifying stuff like the start and stop times of the call ⏱️. If the destination passes, the originating PBX adds a route for that telephone number to its local database, pointing at the URI the proven destination gave it. Plus, the destination hands the originator a token that can be slipped into future call setup messages to authenticate the source of future communications 🔐. Main character energy, no cap 👑.
VIPR also gives you a whole suite of perks that go way beyond just securing where communications come from 💖. It's a routing system that dynamically discovers mappings between telephone numbers and URIs, basically building an ad hoc ENUM database in every VIPR implementation 🧚. The tokens swapped over that out-of-band connection double as an authorization mechanism for accepting calls over the Internet, which seriously cuts down on spam 🙅♀️. And since the token can act like a cookie thanks to that out-of-band connectivity, the VIPR token is less vulnerable to cut-and-paste attacks, so it doesn't need to cover nearly as much of a SIP request with its signature 🍓.
Now, the limitations, bestie 😭. Because of the narrow scope and the details of how it's built, VIPR has some big ones. The most important one for this document is that it only applies to repeated communications between entities. It has no answer for the classic "robocall" problem, where the target gets a call from a number that has never called before 📵. All of VIPR's identity and spam-prevention magic only kicks in after an initial PSTN call has completed and later attempts at communication start up 🥲. Every VIPR-compliant entity also keeps its own stateful database of previous contacts and authorizations. That makes it way more suited to aggregators like IP PBXs, which might front for thousands of users, than to individual phones 📱. That database has to be refreshed by periodic PSTN calls to confirm that control over the number hasn't moved to some other entity, and figuring out when data has gone stale is one of the architecture's challenges 🧩. And because VIPR requires compliant implementations to operate both a PSTN interface and an IP interface, it doesn't have much obvious applicability to regular desktop PCs or similar devices that can't place direct PSTN calls 💻.
The distributed hash table (DHT) also opens up a brand-new attack surface for impersonation 🙈. Attackers who want to pose as the owners of telephone numbers can advertise themselves as routes to a number in the hash table. VIPR doesn't have any inherent limit on how many entities can advertise themselves as routes for one number, so an originator might find multiple advertisements for a number on the DHT even when no attack is happening 🤷♀️. Attackers can also learn from these validation attempts which VIPR entities recently called the target number, even if they can't impersonate the target because they lack the PSTN call detail information. Honestly, that info might be all the attacker is hoping to glean 👀. The advertisements and verifications are public because the DHT VIPR creates is public. That public DHT prevents any centralized control or attempts to impede communications, but those come at the cost of apparently unavoidable privacy losses 🫣.
So because of all this, VIPR, much like SIP Identity, hasn't made much of a splash in the marketplace 📉. VIPR's usefulness as an identity mechanism is ultimately capped by its reliance on the PSTN, especially its need for an initial PSTN call to complete before any of its benefits show up. It's also held back by the drawbacks of the highly public exchanges needed to create the out-of-band connection between VIPR entities. Which means, sadly, there's no obvious solution to providing secure origin services for SIP on the Internet today 💔.
6. Environmental Changes 🌈
6.1. Shift to Mobile Communication
Okay, so since [RFC4474] was first dreamed up, the communications world has changed a LOT 📱✨. The biggest glow-up has been the explosion of mobile smartphones, which are arguably now the dominant communications device in the developed world 👑. Smartphones have both a PSTN and an IP interface, plus SMS and Multimedia Messaging Service (MMS) capabilities 💬. That whole toolkit suggests some of VIPR's techniques could be adapted to the smartphone environment 🧚♀️. The installed base of smartphones is also super upgradable, which means out-of-band rendezvous services that bypass the PSTN can be adopted really fast 🚀. Mobile messaging services that use telephone numbers as identities let smartphone users text each other over the Internet instead of over the PSTN 💌. Like VIPR, these services create an out-of-band connection over the Internet between smartphones. Unlike VIPR, though, the rendezvous service comes from a trusted centralized database instead of a DHT, and that centralized database is what effectively verifies and asserts the telephone number of a message's sender 🏰. Those messaging services only serve their own users, but it seems pretty clear that neutral third parties in a position to coordinate between endpoints could provide similar databases 🫶.
6.2. Failure of Public ENUM
Back when [RFC4474] was written, the hopes for a certificate authority for telephone numbers on the Internet mostly rested on public ENUM deployment 🥺. The e164.arpa DNS tree set up for ENUM could have grown to include certificates for telephone numbers, or at least for number ranges. But it's now clear that public ENUM, as it was originally envisioned, has very little prospect for adoption 📉. That said, some national authorities for telephone numbers are moving their provisioning services to the Internet and issuing credentials that express authority over telephone numbers in order to secure those services 🔐. These new number authorities could provide the public Internet with the signatory authority needed to secure calling party numbers. These systems are far from universal, but the authors of this document believe a solution devised for the North American Numbering Plan could apply to other country codes 🌏.
6.3. Public Key Infrastructure Developments
There have been a bunch of recent high-profile compromises of web certificate authorities 😱. Having numerous trusted certificate authorities in modern web browsers (in some cases, hundreds!) has turned into a seriously big security liability 🚨. Since [RFC4474] relied on web certificate authorities, this is also a lesson for any work on revising [RFC4474] 📚. Innovations like DNS-Based Authentication of Named Entities (DANE) [RFC6698], which designate a specific certificate preferred by the owner of a DNS name, could greatly improve the security of a SIP Identity mechanism 🔒. And when considering new certificate authorities for telephone numbers, we should be wary of excessive pluralism 🙅♀️. A chain of delegation with a progressively narrowing scope of authority (for example, from a regulatory entity, to a carrier, to a reseller, to an end user) is needed to reflect operational practices 🪜. But there's no need to have multiple roots or peer entities that both claim authority over the same telephone number or number range 💅.
6.4. Prevalence of B2BUA Deployments
Given how established B2BUA deployments already are, we may have a further opportunity to review the elements signed using the SIP Identity mechanism [RFC4474] and decide on the value of alternative signature mechanisms 🔍. Separating the elements needed for (a) securing the From header field value and preventing replays from (b) the elements needed to stop men-in-the-middle from tampering with messages might also yield an identity strategy that's practicable in some highly mediated networks 🧠. Solutions in this space must, however, stay mindful of the requirements for securing the cryptographic material needed to support Datagram Transport Layer Security for Secure RTP (DTLS-SRTP) or future security mechanisms 🔐✨.
6.5. Stickiness of Deployed Infrastructure
One thing that hasn't changed, and probably won't change in the future, is the transitive nature of trust in the PSTN 😩. When a call from the PSTN arrives at a SIP gateway with a calling party number, the gateway has very little chance of figuring out whether the originator of the call was authorized to claim that calling party number 🙃. Because of roaming and countless other factors, calls on the PSTN can come from administrative domains that were never assigned the originating number 🌍. This use case will stay the hardest one for an identity system to tackle, and it may prove beyond repair 💀. Still, with the changes in the solution space and a better understanding of the limits of [RFC4474] and VIPR, we're now in a position to reexamine the problem space and find solutions that can have a significant impact on the secure origins problem 🌟.
6.6. Concerns about Pervasive Monitoring
Spoofing where communications come from is already a source of plenty of security concerns 😬. But solutions for identifying communications also have to keep the security risks of pervasive monitoring in mind (see [RFC7258]) 👀. Identifying info, once it's attached to communications, can potentially be inspected by parties other than the intended recipient and collected for all kinds of reasons 🕵️♀️. As stated above, the purpose of this work is not to eliminate anonymity 🫶. And to be viable and in the public interest, solutions should not facilitate the unauthorized collection of calling data 🔥.
6.7. Relationship with Number Assignment and Management 📞✨
okay so telephone numbers are kinda managed in a loose delegation hierarchy 💅 a national regulator might hand off the admin side of numbering stuff, like area codes, to a private neutral entity. then a similar entity hands out number blocks to carriers and other authorized folks, who then assign numbers to customers. resellers with looser regulatory obligations make things messy, and ngl it's hard to tell where enterprises end and carriers begin 🙈 in lots of countries individual numbers are portable between carriers, at least within the same technology (think wireline-to-wireline). and separate databases handle mapping numbers to switch identifiers, companies, and textual Caller ID info. chaotic but iconic 🌈
as the PSTN moves over to VoIP technologies, new assignment policies and management mechanisms are likely to show up 🦋 for example, it's been proposed that geography could play a smaller role in number assignments, that individual numbers could be assigned to end users directly instead of only to service providers, and that assigning a number doesn't have to depend on providing actual call delivery services. wild, right? 😭
databases today already map telephone numbers to the entities that were assigned them, like the LERG (Local Exchange Routing Guide) in the United States 📚 so the move to IP-based networks might be a chance to fold cryptographic bindings between numbers or number ranges and service providers right into those databases 🔐
7. Basic Requirements 💖
this section is only the high-level requirements of the STIR effort 🎀 the authors expect these to get more detailed as the work keeps going:
- Generation: Intermediaries as well as end systems must be able to generate the source identity information. 🪄
- Validation: Intermediaries as well as end systems must be able to validate the source identity information. ✅
- Usability: Any validation mechanism must work without human intervention, for example, without mechanisms like CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart). no clicking traffic lights for us, bestie 🙅♀️
- Deployability: must survive transition of the call to the PSTN and the presence of B2BUAs. 🚀
- Reflecting existing authority: must stage credentials on existing national-level number delegations, without assuming the need for an international golden root on the Internet. the existing hierarchy is already the main character here 👑
- Accommodating current practices: must allow number portability among carriers and must support legitimate usage of number spoofing (e.g., doctors' offices and call centers). real-life businesses need this, so it's not shady 🩺📞
- Minimal payload overhead: must lead to minimal expansion of SIP header fields to avoid fragmentation in deployments that use UDP. keep the packets lean, no bloat 🍓
- Efficiency: must minimize RTTs for any network lookups and minimize any necessary cryptographic operations. speed is everything ⚡
- Privacy: a solution must minimize the amount of information that an unauthorized party can learn about what numbers have been called by a specific caller and what numbers have called a specific called party. nobody gets to snoop on your call history 🙈🔒
some requirements are specifically outside the scope of the effort 🚫
- Display name: this effort does not consider how the display name of the caller might be validated. that's a whole other vibe 💅
- Response authentication: this effort only considers the problem of providing secure telephone identity for requests, not for responses to requests. no solution is proposed for the problem of determining to which number a call has connected [RFC4916]. 📵
8. Acknowledgments 🫶
the authors want to thank Sanjay Mishra, Fernando Mousinho, David Frankel, Penn Pfautz, Mike Hammer, Dan York, Andrew Allen, Philippe Fouquart, Hadriel Kaplan, Richard Shockey, Russ Housley, Alissa Cooper, Bernard Aboba, Sean Turner, Brian Rosen, Eric Burger, and Eric Rescorla for the discussion and input that helped shape this document. literal legends, all of them 🌸
9. Security Considerations 🔐
this document is about improving the security of call origin identification. security considerations for specific solutions will be discussed in solutions documents. this part is not a drill, bestie 💀 the specifics come later, but the stakes are very real 🚨
10. Informative References 📚
[CONCERNS] Rosenberg, J., "Concerns around the Applicability of RFC
4474", Work in Progress, February 2008.
[NEWS-HACK] Wikipedia, "News International phone hacking scandal",
June 2014,
<http://en.wikipedia.org/w/index.php?title=News
_International_phone_hacking_scandal&oldid=614607591>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263, June
2002.
[RFC3324] Watson, M., "Short Term Requirements for Network
Asserted Identity", RFC 3324, November 2002.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
November 2002.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4916] Elwell, J., "Connected Identity in the Session
Initiation Protocol (SIP)", RFC 4916, June 2007.
[RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation
Protocol (SIP) and Spam", RFC 5039, January 2008.
[RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change
Process for the Session Initiation Protocol (SIP) and
the Real- time Applications and Infrastructure Area",
BCP 67, RFC 5727, March 2010.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based
Authentication of Named Entities (DANE) Transport Layer
Security (TLS) Protocol: TLSA", RFC 6698, August 2012.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is
an Attack", BCP 188, RFC 7258, May 2014.
[ROBOCALL-CHALLENGE]
Federal Trade Commission (FTC), "FTC Robocall
Challenge", <http://robocall.challenge.gov/>.
[ROBOCALL-FCC]
Federal Communications Commission (FCC), "Robocalls",
April 2013, <http://www.fcc.gov/guides/robocalls>.
[SECURE-ORIGIN]
Cooper, A., Tschofenig, H., Peterson, J., and B. Aboba,
"Secure Call Origin Identification", Work in Progress,
November 2012.
[SIP-SECURITY]
Peterson, J., "Retargeting and Security in SIP: A
Framework and Requirements", Work in Progress, February
2005.
[SWATTING] The Federal Bureau of Investigation (FBI), "Don't Make
the Call: The New Phenomenon of 'Swatting'", February
2008, <http://www.fbi.gov/news/stories/2008/february/
swatting020408>.
[TDOS] Krebs, B., "DHS Warns of 'TDoS' Extortion Attacks on
Public Emergency Networks", April 2013,
<http://krebsonsecurity.com/2013/04/dhs-warns-of-tdos-
extortion-attacks-on-public-emergency-networks/>.
[VIPR-OVERVIEW]
Barnes, M., Jennings, C., Rosenberg, J., and M. Petit-
Huguenin, "Verification Involving PSTN Reachability:
Requirements and Architecture Overview", Work in
Progress, December 2013.Authors' Addresses 🦋
Jon Peterson
NeuStar, Inc.
1800 Sutter St Suite 570
Concord, CA 94520
US
EMail: jon.peterson@neustar.biz
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7004
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
Hannes Tschofenig
Hall, Tirol 6060
Austria
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at📦 where this page comes from
- ietf: rfc7340 2014-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms