The SIP Forum’s 2023 KYC Summit, held this June, was three days dedicated to discussion of Know Your Customer (KYC), what it is, why it’s important, how it can be accomplished, and how it relates to the goals of achieving a reduction in illegal robocalling set forth by Federal regulators, federal and state enforcement agencies, and the industry.
For those unfamiliar with Know Your Customer, it’s a relatively recent term of art in telecommunications. KYC was initially a set of customer vetting processes established for the financial sector to improve measures designed to assist government anti-money laundering efforts. These efforts weren’t trivial and became especially important in the aftermath of events like the infamous “Silk Road” online marketplace and the 2007/2008 housing and financial crisis.
What kept coming to my mind during the KYC Summit was a concern that KYC was presenting like something a telecommunications service provider did, and then they were done with KYC— a “one-and-done,” as it were. And then the work turns to monitoring traffic, blocking calls on DNO lists or calls using unallocated, unassigned, or invalid calling numbers, looking for and investigating suspicious calls, and relying on anti-robocalling analytics engines (AEs) at the terminating service providers as the final backstop to protect called subscribers.
Some presenters discussed their proprietary data pools and how they can help service providers monitor traffic. It's great for service providers to do that due diligence, but how do we tell which service providers are doing those checks and reward them for it?
For an exclusive in-depth look at KYC and monitoring, check out Numeracle’s KYC Policy Guide and the companion whitepaper Call Record Review for KYC and Fraud Mitigation.
It seemed to me two areas were strongly related, but their relationship was not fully explored, and that was the relationship between:
One of the things I like about STIR/SHAKEN call authentication is it provides the analytics engines (AEs) with more information about a call than would otherwise be available without call authentication. The SHAKEN Personal Assertion Token (PASSporT) that is in the body of a SIP “Identity” header is used to validate the integrity and authenticity (but not the provenance) of the calling and called numbers in a call attempt. Additionally, the SHAKEN PASSporT includes a timestamp (helpful for thwarting replay attacks) and an attestation about whether the entity which authenticated (i.e., signed) the call had some useful knowledge about the caller and their authoritative right-to-use of the calling number.
Note AE integration of STIR/SHAKEN information varies. The AE vendor providing anti-robocalling may not be the same vendor providing STIR/SHAKEN call signing and signature verification and so extracting data from a call signature and using it as part of the input to anti-robocalling analysis requires the service provider to play the role of the integrator. And, where a single vendor is used for both anti-robocalling and call authentication, different groups may be in silos doing independent development.
The FCC issued a rule permitting US service providers to block calls using “reasonable analytics” (on an opt-out basis). Perhaps we can assume that KYC is the foundation for acquiring a set of reliable identity and trust attribute criteria suitable for establishing reasonable trustworthiness.
Then let’s assume “reasonable trustworthiness” can be defined sufficiently through a program of accreditation, that we can then directly, or in references, use call authentication protocols and verifiable resources such as X.509 security certificates and W3C Verifiable Credentials to give the AEs real-time access to verifiable identity and trust attribute information to prove reasonable trustworthiness of a caller and their calls.
What should be the result of “reasonably trustworthy” actionable KYC data in call authentication?
Let’s explore what it means to provide “reasonably trustworthy” and actionable KYC data.
The analytics engines can learn more about a caller in two ways: in-band and out-of-band (STIR/SHAKEN call authentication uses a combination of the two).
Calling and called numbers are generally learned in-band from call signaling. Additionally, some callers register their calling numbers out-of-band with various AEs, either through something like the freecallerregistry.com website or directly with each AE using APIs, spreadsheets and e-mail, or whatever other mechanisms each AE created for accepting registrations and requests for remediation (ostensibly for calls accidentally mislabeled or blocked).
The SHAKEN PASSporT is sent in-band in a SIP INVITE. It provides integrity information authenticating the calling and called telephone numbers, as well as a full, partial, or gateway attestation describing the purported relationship between the call signer and the caller and an inference (but not a guarantee) about what the signer is indicating they know about the caller and the caller’s right-to-use of the calling number.
For a deeper dive on exploring attestation levels and call authentication, save your spot for our upcoming webinar with the Mobile Ecosystem Forum (MEF).
To verify the integrity of the calling information in the SHAKEN PASSporT received in-band, a STIR/SHAKEN Verification Service (VS) must download an X.509 security certificate (chain) from a file server which is an out-of-band function.
So what can SHAKEN data tell the AEs with access to this information?? If verification is successful, it tells the AE that the calling number and the called number were not changed in transit between the service provider who signed the call and the VS that verified the signature. The verified SHAKEN PASSporT attestation hints whether the signing service provider knew the customer and whether they had a right-to-use call number.
However, attestations are not always trustworthy for various reasons. And knowing the calling number didn’t change after being signed is not extremely valuable. Spoofing of calling numbers happens before the signature is applied because STIR/SHAKEN verification will fail if the number is spoofed after the signature. That means spoofed numbers are routinely signed (and successfully verified because they don’t get changed in transit). And it turns out that sometimes A-level (aka “full”) attestations are assigned to calls that should have instead had a B-level (partial) or C-level (gateway) attestation.
So the AEs are in a tough spot with trying to do integration with STIR/SHAKEN partly because some of them don’t also do STIR/SHAKEN verification and instead rely on the output of a verification which is most often the text value of “TN-Validation-Passed” in a verstat (verification status) parameter in a SIP INVITE, and only if the call was signed with A-level attestation. By convention (i.e., not by standard), verification services at terminating service providers do not include any of the other standard values in the verstat parameter and have a verstat only if the attestation in the SHAKEN PASSporT was an A.
Why aren’t the other standard values used? Wouldn’t following the standard and including those other B and C values where appropriate provide more information to the AE and, for that matter, to the called subscriber? Yes, but there was a long debate about how the data could very likely be misinterpreted, and in the end, the service providers decided on the convention rather than the standard.
But again, how does all this STIR/SHAKEN signing and signature verification relate to actionable information discovered and available via KYC processes and help AEs in their difficult job of protecting subscribers from illegal robocalls?
The most essential information learned from verifying a SHAKEN PASSporT is the signing service provider's identity; ironically, that identity information is not in the SHAKEN PASSporT. Instead, the identity is contained in the end-entity X.509 security certificate in the certificate chain that was downloaded, out-of-band, validated, and parsed to obtain the “public key” used to verify the SHAKEN PASSporT.
The identity of the signing service provider is in the end-entity certificate in two places. The first place is the “Subject” field which contains the so-called Distinguished Name (DN) and its subfields. The second place is in the Telephone Number Authorization List (TNAuthList), and it is a Service Provider Code (SPC) which by convention is a National Exchange Carrier Association (NECA) Operating Company Number (OCN).
For example:
Subject: C=US, ST=Washington, L=Bellevue, O=T-Mobile USA, Inc., OU=Core Network Engineering, CN=SHAKEN 6529
The Common Name (CN) subfield in the example is “SHAKEN 6529”. The text in the CN is per the SHAKEN standards, which specify the CN should be the word “SHAKEN” followed by the SPC, which in almost all cases is an OCN.
The SPC in the CN of the DN and the TNAuthList of a SHAKEN certificate is KYC-vetted information and cryptographically signed by the Secure Telephone Identity (STI) Policy Administrator (PA) and verified by the STI Certification Authority (CA) that issued the end-entity certificate. The identity of the signing service provider is actionable information learned by KYC vetting of the signing service provider.
AE algorithms can build a reputation of a signing provider’s identity based on the analytics results of the calls signed by that provider.
Do the AEs use signing service provider identities in their algorithms? If so, is this enough? The answer to the first question is known for certain only to the AE providers and possibly the service providers they support. The answer to the second question is, in my opinion, no. And THAT is an opportunity!
Call signing by service providers using standard SHAKEN PASSporTs and verified by their associated STI certificates is only some of what is possible. There are currently four different kinds of PASSporTs that have been or are being defined:
The first three PASSporT types are already standard (although the 2nd and 3rd are infrequently used or supported). The Internet-Draft standard of the fourth type of PASSporT, “rcd,” is in its 26th (and most likely final) version. An RCD PASSporT contains a very flexible set of information elements that could be used to identify not just the identity of the signing service provider but potentially of the caller themselves, and even signed by the caller themselves.
The “rcd” specification also authorizes service providers to include “rcd” PASSporT “claims” inside of a SHAKEN PASSporT. The claims most often cited are “nam” (name), “icn” (icon), and “crn” (call reason). The icon claim contains a URL reference to an icon file. The call reason claim contains text describing the reason for calling.
The name, logo, and reason for calling are all information that could be vetted during KYC and onboarding processes and now, thanks to the RCD PASSporT (or “rcd” claims in a SHAKEN PASSporT), bemade available in-band to an AE, the terminating service provider they support, and the terminated service provider’s subscribers (in theory).
Great! We’ve identified standards for passing additional actionable information about a caller, including possibly their digital signature on an RCD PASSporT and their identity in the associated X.509 security certificate (downloaded out-of-band). Can the AEs and their service providers trust the new information? The answer, unfortunately, is not necessarily, and not easily. It would take another whole blog to go into the reasons why. Please let us know if you are interested and want more details.
So what have we learned?
KYC practices can act as the fundamental and foundational set of vetting and risk assessment processes needed for a service provider to discover reliable identity and trust attribute information about their customers and upstream providers.
But where do we go from here? What should telecommunications service providers do to more effectively capture and exploit actionable, verifiable identity and trust attribute information discovered using accredited KYC processes?
The conversation on KYC needs to transition from describing what KYC processes are and how to implement them to a discussion on what information should be discovered, stored, and transmitted to AEs, the terminating service providers, and their subscribers via in-band and out-of-band processes.
I introduced the term “trust attributes.” We don’t often talk about those, but they are the companion information, which, combined with an identity, represents an entity's relative trustworthiness. This sounds academic, and in the context of designing data structures and communications protocols, it is academic, but the real world is replete with common examples of discoverable trust attributes:
The answers to these questions can be encoded, stored, transmitted, and, if necessary, obfuscated to protect privacy and sensitive proprietary information.
Call authentication standards, including RCD, do not yet embrace the level of detailed identity and trust attribute information needed to reliably provide AEs with “reasonably trustworthy” call authentication that can be used to:
The call authentication standards need to evolve beyond the 1st generation of STIR/SHAKEN standards and protocols and look beyond to the challenge of storing and transmitting identity information learned via KYC. This evolution needs to be eyes wide open about the layers of identity involved in a single call, especially the calls of enterprises and agencies. Those identity layers often include the signing service provider, the outbound call center, and the brand. Still, they more broadly could consist of telephone number assignment authorities, state business license bureaus, security bond underwriters, legal entity identifiers such as are issued by accredited Local Organizational Units (LOU) of the Global Legal Entity Identifier Foundation (GLEIF), and more.
The bottom line is STIR/SHAKEN scratched the surface of what is possible and effectively provided the foundation for authenticated communications, but it’s time to go beyond 1st generation models of identity information and verification to explore the art of the possible and then make it a reality.
Pierce’s voice has been influential in shaping the standards, architecture, and deployment of technologies critical to the continuous advancement of the telecommunications industry. He most recently served as Principal Engineer of Systems Architecture at T-Mobile, responsible for voice architecture development for VoIP robocalling protection and STIR/SHAKEN call authentication design and standards development. During his 30-year tenure at Sprint in senior design roles, he drove cooperative development and implementation of next-generation voice and VoIP signaling, routing, and services architecture.
Pierce’s contributions to the industry also include membership in four ATIS working groups, all three of the FCC's North American Number Council (NANC) Call Authentication Trust Anchor (CATA) working groups, the Secure Telephone Identity (STI) Governance Authority (GA) Technical Committee as the representative from T-Mobile, and the Cellular Telecommunications and Internet Association (CTIA) Technical Committee in support of the Registered Caller branded calling initiative. He has also actively participated in the US Telecom Association (USTA) Industry Traceback Group (ITG), SIP Interconnection Working Group hosted by NTCA, and the Internet Engineering Task Force (IETF) Secure Telephone Identity Revisited (STIR) working group.
