Third-party signing undermines SHAKEN

Can a downstream provider sign calls with STIR-SHAKEN? Does this make the originating service provider a SHAKEN participant? We hear this question often, and it’s come up in a recent FCC document. Let’s review the regulations and standards.

In their Fifth Further Notice of Proposed Rulemaking (FNPRM) on SHAKEN, paragraph 224, the FCC refers to this practice as “STIR/SHAKEN by Third Parties.” This happens when a downstream intermediate provider signs calls using their own SHAKEN certificate, while the Originating Service Provider (OSP) claims that they’ve implemented SHAKEN, even though they don’t have a SHAKEN certificate.

This practice has become an important issue for several reasons:

1. It facilitates illegal robocalls. Robocall-friendly OSPs send robocalls to a downstream provider to be signed B or C. Nobody is held accountable. Illegal robocalls flourish.
2. The STIR/SHAKEN standards include a governance framework in which the Policy Administrator approves voice service providers for participation. If providers misbehave, then their approval is rescinded. Third-party signing evades these controls. Robocall-friendly OSPs claim they’re doing SHAKEN, but they’re outside of the system. They’ve found a safe place to keep sending robocalls.
3. Third-party signers don’t know much about the calls they’re signing. They don’t know the customer. They don’t know whether the customer should be using that calling number. Their SHAKEN attestation isn’t worth much.

Here’s a quick summary of the rules and regulations that will help us sort through this.

Regulations

These definitions will help us sort this out.

The First Report and Order on SHAKEN, paragraph 36, defined these standards as ATIS-1000074, ATIS-1000080, and ATIS-1000084.

When an intermediate provider relays a call, it is not a voice service provider because it isn’t dealing with the end user. The OSP is the voice service provider.

And here’s the SHAKEN requirement:

So, how does all this square with third-party signing?

1. The OSP is the voice service provider. They’re supposed to fully implement SHAKEN in their network. They haven’t done that.
2. The third-party downstream provider is not the voice service provider. They’re serving the OSP, not the end user.

Clearly, the third-party signer arrangement does not comply with the regulations. Let’s see how it fares with the standards.

Standards

ATIS-1000080 Governance model

ATIS-1000080 describes the governance model. Why do we need a governance model? To define and manage a trust model that protects the integrity of the call authentication framework. Why is trust important? Well, what would happen if bad actors found it easy to get their illegal calls signed and the signers weren’t held responsible? The integrity of the SHAKEN ecosystem would collapse.

ATIS-1000080 describes a process where a voice service provider applies to the Policy Administrator for approval to obtain SHAKEN certificates. Once approved, they can obtain a SHAKEN certificate from an approved STI Certification Authority. The provider uses the certificate to sign calls with SHAKEN information. If a service provider misbehaves, their certificate can be revoked.

How does the third-party signing arrangement look from a governance perspective? Not too good. OSPs are getting their calls signed downstream, which is fine, but they’re also claiming that they’ve implemented SHAKEN, which is not true. They are completely outside of the SHAKEN governance framework.

What would happen if bad actors found it easy to get their illegal calls signed? That’s exactly what’s happening with many calls sent within the third-party signing arrangement.

ATIS-1000074 Standard on SHAKEN

ATIS-1000074 is one of the standards listed as defining SHAKEN in the First Order. Section 5.2.4 describes three levels of attestation.

So, how does third-party signing stack up against these standards? Not very well.

Attestation levels A and B require the signing provider to be responsible for the origination of the call onto the IP-based network. But in the third-party signing arrangement, the OSP originates the call onto the IP network—the third-party signer does not.

Furthermore, for both A and B attestation, the signer must have a direct authenticated relationship with the customer. In the third-party signing arrangements, the downstream intermediate provider does not.

Recap

• OSPs are supposed to fully implement SHAKEN in their network. OSPs that rely on third-party signers haven’t.
• OSPs claim SHAKEN implementations, but they haven’t been approved for SHAKEN. They are outside of the governance framework.
• Third-party signers do not originate calls on the network, do not have a direct authenticated relationship with the customer, and have not verified the association between the customer and the calling number. They should be signing these calls with C attestation.
• We have observed that calls signed with B or C are six times more likely to be robocalls than unsigned calls.

The third-party signing arrangement does not comply with either the regulations or the standards, and it’s undermining the integrity of the SHAKEN ecosystem.

TransNexus solutions

TransNexus is a leader in developing innovative software to manage and protect telecommunications networks. The company has over 20 years’ experience in providing telecom software solutions including toll fraud prevention, robocall mitigation and prevention, TDoS prevention, analytics, routing, billing support, STIR/SHAKEN and SHAKEN certificate services.

Contact us today to learn more.