Eric Priezkalns: Welcome to Tuesday Talks, a live discussion series where we bring truth and shed light across the brand identity and the communications industry. I'm Eric Priezkalns, Chief Executive of the Risk & Assurance Group and Editor of Commsrisk.com, here to do a Tuesday Talks takeover as your host.
Joining me is industry legend Pierce Gorman, Distinguished Member of Numeracle's Technical Staff. Pierce, we had such a good time with our conversation last time that I know you're also looking forward to today's show.
Pierce Gorman: Oh, yes, I'm looking forward to it. I don't know if I'm the legend, but as I said last time, I am an industry veteran. I have 34+ years of experience, the last several years working on call authentication technology, specifically the development and implementation of it. I was the lead engineer at Sprint for implementing our STIR/SHAKEN solution. If folks want to know more about my background, they can look up the Numeracle Inside the Innovator's blog, which talks about my thoughts and experiences.
Eric Priezkalns: I can guarantee everybody at the end of this half-hour show will consider you a legend if we can get through all this amazing content we've got lined up for today's show. So we're back; this is the sequel, part two of our previous podcast, "Global Call Authentication Domination." We're interested in domination not because we want to be dictators but because we're talking about addressing worldwide problems. That means there will be some toing and froing as different parts of the world wrestle with how best to work together and whose proposed solutions will be widely adopted.
During that first show, you let me voice some of my criticisms of the current U.S. strategy for tackling nuisance robocalls. But let's not be negative; let's be positive. Let's talk about the positive ways that the industry can restore confidence in phone calls. Much of that restoration and preservation of trust will revolve around ensuring that the apparent origin of a voice call matches its real origin, thus reducing the risk of scammers tricking consumers. We're also going to talk about how the ways and methods used to protect subscribers could also be used to protect telcos from being defrauded.
STIR/SHAKEN, as we discussed in our previous episode, takes a big step in authenticating phone calls by applying a digital signature to those calls, ideally, but not always at the call's origin. Let's reestablish the foundations for progress by revisiting the role of Rich Call Data, RCD, in delivering trustworthy calls and how it relates to STIR/SHAKEN and the use of signatures more generally. Could you please summarize, for the benefit of those less technical people like myself, the role that is being played and should be played by Rich Call Data?
Pierce Gorman: I've got a lot of material to cover, as you mentioned, and a lot of it is from a technologist's perspective, and it's fairly technical. Apologies in advance for anybody who struggles with some of what I'll try to cover regarding the value and what's relevant about RCD, or rich call data, but I'll call it RCD.
This is the first opportunity that the actual originator of a call will be able to authenticate the call and present information about themselves insofar as their identity is well established. There's information available for the verifier of the call so that they can be confident of the trustworthiness of that identity. That's going to be an important value.
I assume we'll first see this for enterprises and call centers so their calls can be verified. They'll get a little green checkmark, and then they could also display a company logo, company name, and even the reason for calling. That's an important branded calling aspect. Where RCD came from was a problem recognized early on in STIR/SHAKEN development. There was a concern about the Attestation in a STIR/SHAKEN call, which tells the terminating service provider whether it's a call that the originating service provider who signed this call has a number that belongs there.
One of the primary reasons for STIR/SHAKEN was to combat number spoofing. It's difficult for an originating service provider with a customer who may have more than one service provider, like a large company that has connections to maybe Verizon and AT&T where Verizon is getting the call, but it has an AT&T number on it, so they don't recognize it. They can't give it full Attestation, which frustrates the customer because they're a big important client paying for the service.
Why can't they have that A-level attestation? There was work done in the Alliance for Telecommunications Industry Solutions (ATIS) to do a technical report where they reviewed different ways this problem might be solved. One that's gotten the most momentum is the one that's called Rich Call Data. What RCD does is it uses the STIR/SHAKEN technology, which is a digital cryptographic signature that's passed along in the SIP invite.
The RCD is an extension of the same signature as the SHAKEN signature, but they're slightly different. There's a basic signature called a personal searching token called PASSporT for short. SHAKEN is an extension on that basic PASSporT, and RCD is a different extension on that same basic PASSporT. But RCD covers the sorts of content that an individual or an enterprise or government agency would want to present about themselves, including a company logo and the reason for calling.
Still, there is a lot more data that it can include. The signature allows for a virtual card (V card), like a business card. J card is a JSON encoding of a V card, and there are many properties there that could be presented, like location and all sorts of things. I would call RCD a groundbreaking opportunity for businesses and people to present information about themselves that could be used to improve the chances that the call gets completed.
Eric Priezkalns: I'll jump in straight away there. When we talk about an RCD signature and compare that to a SHAKEN signature, and you refer to RCD as being an extension, does that mean that they're both essentially built upon the same STIR protocol? Are they both compliant with STIR, or am I misunderstanding?
Pierce Gorman: No, you understand absolutely correctly. STIR is the name of the working group in the Internet Engineering Task Force (IETF). They're the same people who developed TCP/IP. The STIR working group stands for the Secure Telephone Identity Revisited. They did that partly because the protocol that it works with is a Session Initiation Protocol, also known as SIP. There are lots of jokes about anything that works on SIP having to do with drinking. So we added STIR, and then they added onto that with something called SHAKEN.
But yes, the basic signature there is a basic PASSporT. That's what we call the base PASSporT. Currently, there are four different PASSporTs that have been defined. SHAKEN was the original one that was done so that carriers could authenticate and verify calls amongst themselves. This is what's been required by the TRACED Act and what is mandated by the FCC.
Then beyond that, there are additional extensions on that base PASSporT for calls that are forwarded, that have diversion, and then calls that have resource priority requirements such as government emergency telephone services or just emergency services in general, and then also the RCD PASSporT. You have the SHAKEN Div RPH and then RCD.
Eric Priezkalns: So it's essentially built on the same concept of including information in the SIP header to provide some additional data to the telco who is processing that call later on down the line or to the terminating telco so the telco can then go back and verify the origin of the call. It's all built on the same platform, but there are different data flavors, therefore, included. What makes RCD distinctive? Does it include more data than the other kinds of signatures?
Pierce Gorman: It is including more data, but it's also specific to the type of call that it's being used for. The Div is specifically to assist with knowing that a call has been translated and that it's being forwarded, so there's a specific procedure with specific information included with that signature. RCD is the same kind of idea. In the case of RCD, you're trying to present information.
Remember, this comes back to trying to support enterprises who might have dual homing arrangements; that's what it's called in the technical report. The idea is that if the enterprise had good identity information that is trustworthy and can be verified to be trustworthy and included within that signature, then that RCD PASSporT makes it to an originating service provider responsible for putting a STIR/SHAKEN PASSporT into that same call. They could look at that information even though that customer may not be directly attached to them, or they may be directly attached to but are using a number that the service provider doesn't recognize because they didn't assign it.
They could look at that information and satisfy themselves about the provenance and the right to use the calling number. They'll know that it wasn't spoofed and they can be comfortable assigning an A-level attestation to the STIR/SHAKEN call. When it gets to the terminating service provider, even if the terminating service provider didn't necessarily support RCD, they could at least see the A-level attestation and verify the call and give it the verification status that allows the call to be displayed as verified in a green checkmark, either at the time of the call or in the call log in the case of Apple devices. Does that answer your question?
Eric Priezkalns: Yes, and there's so much to ask as well. The next thought that I have in mind immediately is to ask if RCD is something that's in place already. Are people using it already, or is there a timeline for its adoption?
Pierce Gorman: There's a timeline for its adoption. It is being tested and has been used for a couple of proof-of-concept demonstrations (in which Numeracle has been involved!).
One was done by Comcast two years ago and then one by T-Mobile that was done last year. The standard itself is an Internet-Draft Last Call, so it should become an RFC request for comments and an official standard in the IETF soon. The folks that have been working on developing it and being able to support it, I assume, will be able to start having those calls signed and displayed sometime next year.
Eric Priezkalns: The big motivation or the big reason why RCD may gain some rapid momentum behind it is that businesses and enterprises want people to pick up their phones and want people to answer their calls, and therefore they have a great incentive to make sure this works and to have it adopted. Is that why you expect RCD will be a big influence in how we see authentication going forward?
Pierce Gorman: Yes, that's a big reason. There is a lot of interest in being able to do branded calling where more information than just the calling number and the calling name can be displayed. The company logo would be beneficial, and a reason for calling on top of that is considered to be a big boost to help people know why they should answer the call. So yes, that's a big reason.
Eric Priezkalns: I was curious about this when it was described. What does it mean for my handset to tell me what the call is about? I mean, what kind of field is this? Is there an example that's given in the working group when discussing this? What would the actual handset show me in such a situation?
Pierce Gorman: The most common example I've seen described is Home Depot saying a delivery is on the way, or that sort of thing. The display that was done for Comcast was done using a soft client on a Caller ID to the TV. There isn't a standard for that, so each cable provider that provides telephony services that does Caller ID to the TV will do something with this soft client.
There is no standard for what the call validation treatment with the display is supposed to look like on any device, whether it's a TV or a mobile device, or anything else. But there has been some commonality in its implementation. For older style Caller ID displays that you might have on a cordless phone if anybody still has one of those, Comcast has used a [V] for verified calls to let folks know that the call has been verified.
That was also used with their soft client in the T-Mobile presentation last year that was done on an Android device. There was the logo, of course, the calling number, the calling name, everything that people are used to seeing. Well, I shouldn't say they're not used to seeing the logo, but they're used to seeing the calling name and then the caller number. The reason for the text was pretty small. There is work going on to try and improve that, but it was just a message right on the same dialer as what you would see for any call. So that would be what it would look like.
Eric Priezkalns: Now, one of my criticisms that I have of the current US strategy is that it's easy to subvert what's called 'authentication' if you don't have adequate Know Your Customer procedures in place. So yes, something is authenticated, and there's a technical sense of the word authenticated, but in reality, somebody's being dishonest because they've been allowed into the ecosystem, and now they're exploiting the authentication mechanism to reach people through a process of deception. What would differ in RCD to prevent that from happening?
Pierce Gorman: Great question, Eric. That leads to the second part of what I wanted to cover, which is delegate certificates. But you hit on a very key point, which is that, yes, that additional information is influential, and it makes people want to answer the phone. If number spoofing was bad, then logo spoofing and reason for calling have got to be even worse if it's allowed to occur. It's really important that there has to be a good job of Knowing Your Customer and documenting that the image that's being displayed is, if it's a trademarked image, that it's the actual company that owns the trademark that's sending it, and that there's no objectionable material, whatever 'objectionable' means.
There's a lot of work that has to go into vetting the content to make sure that it's safe to display. Now, what is the technology or what is the procedure and method, and what are the policies that are in place to ensure that happens? I'm going to say that there needs to be some work to sure those up. It's one of the reasons why I think it's really important for businesses who want to take advantage of this should encourage and engage with the technologists and with the developers.
The folks that came up with STIR/SHAKEN, are fairly open organizations. The IETF is a fairly open organization, and so is the SIP Forum, which is one-half of the SIP Forum ATIS Joint Task Force and IP-NNI that developed the STIR/SHAKEN standards. If you think about SHAKEN as being a standard that operates between service providers, that was required by law and by mandate, and this being something much more open that's going to be used by businesses, if you think about carrier-to-carrier call authentication, that's 35,000-45,000 service providers in the United States, which surprises a lot of people that it's a big number.
If you think about the fact that there are, let's say, 30 million businesses in the United States, many of them proprietorships or individuals operating a business, the quantity of call authentication and the requirements that need to be thought about for call authentication for enterprises and agencies far outstrips what we've been doing for SHAKEN. RCD is a much bigger deal to me than anything we ever did with SHAKEN.
Regarding what needs to be sured up within the policies and standards, I'll get into delegate certificates. Basically, make sure that you have a good KYC policy in place. There are two things I'll mention on this as far as how it relates to SHAKEN. In SHAKEN, it operates between carriers and SHAKEN also permits the idea of RCD claims. You have an RCD PASSporT, and you also have what's called an RCD claim. RCD claims can be included inside of a SHAKEN PASSporT.
As an enterprise, you might generate an RCD signature, you put it in your call, you send it to your originating service provider, they look at that and decide to give you an A-level attestation on your SHAKEN PASSporT and strip out all your RCD claims and drop them into the SHAKEN PASSporT. They'll discard the RCD PASSporT. Now you just have a single SIP identity header in the call that gets sent down to the terminating service provider. The terminating service provider gets the call, sees it has an A-level attestation, and decides this call is going to be verified. They also see the RCD claims in there.
Should they trust these? Should they display them? In almost every instance, I'd say that the terminating service providers ought to be saying, no, I'm not going to display these RCD claims. They would do that because they don't know what the originating service provider has done to vet the customer, to know that those claims are legitimate and should have been displayed.
If we think about the fact that we're doing call authentication SHAKEN at all because of service providers who admitted illegal robocalling onto the public switch telephone network, then you should assume, and I would as a terminating service provider, that there are going to be service providers who are not only admitting illegal robocalls into the PSTN but are also sending the RCD claims in their SHAKEN PASSporT. There's no way for any terminating service provider to have bilateral agreements where they can be indemnified or make sure that the sender of those claims accepts liability.
Maybe the large service providers, Verizon, AT&T, and T-Mobile, could get together and say that because they're big people, they will do a good job, so if they send you a call, you accept it, you display my stuff. They could do that. Now, will they do that? I don't know. This is new ground to be covered. So I don't know if that would happen.
But what I know won't happen is they won't blindly accept RCD claims in SHAKEN PASSporTs from originating service providers, just carte blanche without any concerns. What's required is those RCD PASSporTs themselves need to be able to get to the terminating service provider or eventually even to the terminating device. I could see where Apple or Samsung or other mobile device operators or anybody who's making devices that can understand SIP might want to see those RCD PASSporTs because they'll verify it themselves. They won't need the terminating service provider to do it for them.
There's data in there beyond just those claims they'd like to see and be able to analyze and use that information. The point to all of that is when terminating service providers want to be able to display the information that is sent to them in RCD, they need some way to be confident of the trustworthiness of the data. That is not something that is currently baked into the policy or into the standards. There's work going on in different arrangements to try and figure out how to manage that. I have my own ideas about how to do that.
That should be another Tuesday Talks with you because you have worked on this same technology that I think is interesting for this problem space.
Eric Priezkalns: Let's not leap ahead. That's great, and I love the show, so I'd be glad to come back and discuss it again, but let's not leap too far ahead. We've mentioned delegate certificates a few times. Briefly, for the less technical audience members like me, what are we talking about when we talk about delegate certificates, and why is it relevant to this topic?
Pierce Gorman: I'll start with how STIR/SHAKEN works as a baseline, and then we'll talk about delegate certificates in relation to that. STIR/SHAKEN works is that an originating service provider creates a signature over some information and SIP invite, which is the call attempt, before sending it to the terminating service provider. In there, there's a reference that says, if you'd like to be able to verify my signature and this data to make sure that it's authentic, here is a web server or file server that you can go to to download a public cryptographic key that I've made available to anybody who wants to see it. You could use that public key to validate the signature and make sure that it's authentic and that it came from me.
Now, where do those certificates come from? What's in those certificates? The certificates are provided by what's called Certification Authorities (CA), and there are big-name CAs that people are familiar with. GoDaddy is a big certification authority, and they also manage domain name services and there are others. They provide certificates that are used for the web so that when you connect to your bank, and you see the little green lock up on the browser, it says you have an authenticated connection with your bank. That was done using cryptographic signatures in HTTP protocol. We're doing cryptographic signatures in SIP protocol, so it's a very similar thing.
The certification authorities that are used for STIR/SHAKEN are not the big-name Certificate Authorities who were aware of the work but thought about the fact that 35,000 service providers are not going to change very often. So 35,000 certificates are not worth their time and effort to even look at using this or doing much with it. If you ever advance to the point where we're using thousands or millions of certificates, that'll get more interesting, and we can maybe re-engage at that time.
There were several small companies that are already working with service providers regularly and decided to become a Certification Authority. Becoming a Certification Authority means that you have to have a Certificate Policy available to you. What is the policy that my certification practice statement needs to adhere to? So there's a Governance Authority (GA), there's a Policy Administrator (PA), and then there's the Certificate Authority (CA). To become a Certification Authority, you create a Certification Practice Statement that gets submitted to the Policy Administrator (Policy Management Administrator/Policy Authority).
The Policy Management Administrator at the Policy Authority, which is iconnectiv for the United States, reviews that Certification Practice Statement. If they like it, you get a thumbs up from them, and become a Certification Authority. They also have to submit that to the Governance Authority Technical Committee. So a PA and a GA have to review the Certification Practice Statement, so it's not easy to become a Certification Authority.
The CAs then can create a root-level certificate with a public key, they've used a private key to do that, and then they issue certificates from that certificate. They sign intermediate certificates with their private key. Those intermediate certificates create a very short chain of certificates that prove that they signed it and are the trusted third party. If you get a certificate that has them in the certificate chain, you know that it came from them and that they authorized it.
For STIR/SHAKEN, there is a triangle between the Certification Authorities, the PA, and the carriers. When a carrier wants a certificate, they request a service provider code token from the PA, they include that in a certificate signing request that they send to the CA, and the CA gives them a certificate. They post that certificate publicly and use the private key to sign their calls. People download the cert to verify the call. That's how STIR/SHAKEN works for carriers.
That works well because the carriers have to register with the PA, and the PA vets them to be able to get those STIR certificates. But how does an enterprise get a STIR certificate? The quick answer is, that they don't. They're not allowed to have STIR certificates. Only service providers are allowed, and those responsible organizations with toll-free numbers and service providers that have an operator carrier number code.
So how does an enterprise get certificates? They go to somebody like AT&T or T-Mobile and request a certificate. AT&T or T-Mobile can, as a service provider that can get certificates from that triangle, request a subordinate Certification Authority certificate and then issue the requesting enterprise a delegate certificate. The idea is that enterprises would need to go to their service provider, who has the ability to become a subordinate Certification Authority and get a certificate from them.
Does that make them good and secure where you can trust the information that came from them? Well, those same service providers admitting illegal robocalls into the PSTN can legitimately ask for the authority to issue delegate certificates. So no, you can't. That comes back to that problem of keeping in mind that the policies and standards don't yet make sure that you're safe, so you have to have something outside of those two to be able to make sure you're safe.
There is work going on by different organizations to identify how to do that. When you look inside of a certificate, a STIR certificate, there's a special field there called the TN Authorization List. That field says this telephone number or these telephone numbers or this service provider is authorized for this call.
Eric Priezkalns: It's really difficult for you to compress this into the time we have available. I still want to cover a couple of quick questions that the audience has submitted. Is there an organized group of leaders who are having these conversations about global standardization? If not, how can we move to establish this?
Pierce Gorman: There is not. The likely organization you'd want to use would be GSMA (Global System for Mobile Communications), ITU (International Telecommunications Union), 3GPP (3rd Generation Partnership Project)... but there isn't. You might want someone like ITU or some other organization and then liaisons amongst the organizations to make it work.
Eric Priezkalns: I think I know the answer. We're going to get Rebekah to do it, and I'm going to help out, and you're going to help out. I think we just need to grab the mantle on this because otherwise, we'll be waiting for other people who will not deliver the answer. Another quick question for the audience, what is the state of play for initiatives for CLI validation via distributed ledgers? I know that might take you half an hour to answer, so can you say in 1 minute what's the state of play CLI validation via distributed ledger, or do we need another show to do that?
Pierce Gorman: We need another show. There is a group called the Distributed Ledger Technology Group (LTD) that's part of the Alliance for Telecommunications Industry Solutions, or ATIS, and they've been working on this problem for a year or so. There's lots more work left to do.
Eric Priezkalns: There is a lot more work to do. Thank you to those people who submitted the questions; it was much appreciated. I suspect we will have a part three because there is no way to condense this topic down to the time available. Though you certainly earned the title of legend today, Pierce, in trying to get through all that content in the time available. You've definitely earned it today.
Thank you to all of you who joined us today for another episode of Tuesday Talks. It was great to lead the conversation as the first non-Numeracle host. Pierce and I will be having a follow-up conversation planned on Global Call Authentication, and next time around, we'll be including Jim McEachern of the Alliance for Telecommunications Industry Solutions (ATIS), so join us for our next Tuesday Talks session on September 13th. We look forward to seeing you there!
