Delegate certificates improve STIR/SHAKEN

STIR/SHAKEN allows originating service providers to attest to the calling party’s authorization to use a calling number for a call. But what happens in customer-of-customer scenarios, where the provider that issued the number doesn’t know the end customer who was ultimately assigned the number? That’s a situation where delegate certificates can help.

Delegate certificates build on and extend the governance and trust that’s the foundation of STIR/SHAKEN. Here’s a quick review.

Triangle of trust

STIR/SHAKEN uses a governance model that provides a triangle of trust. Bad actors, who wish to spoof their calling numbers, cannot participate. This gives participants who rely on SHAKEN confidence in the call authentication. The triangle of trust involves the following:

• Policy administrator (STI-PA). Vets and approves certificate authorities and service providers to participate in the SHAKEN ecosystem
• Certificate authorities (STI-CA). Issues SHAKEN certificates to approved service providers.
• Service providers. Creates SHAKEN PASSporTs to attest to call authentication. The PASSporT is cryptographically signed and includes a reference to the SHAKEN certificate that relying parties use to verify the authentication.

Triangle of Trust

Attestation

There are three defined levels of attestation that can be used by an originating service provider:

1. Full Attestation. The signing provider has a direct authenticated association with the customer and can identify the customer. The signing provider also has established a verified association with the calling telephone number.
2. Partial Attestation. The signing provider has a direct authenticated relationship with the customer and can identify the customer. However, the signing provider does not have a verified association of the calling number with the customer.
3. Gateway Attestation. The signing provider is responsible for putting the call onto the IP network but has neither an authenticated relationship with the customer nor a verified association of the calling telephone number.

Customer-of-customer scenarios

There are many scenarios where a SHAKEN-authorized service provider does not have the information necessary to sign a call with full attestation. However, if we follow the chain along which the telephone number was assigned, the next VoIP Entity may have the necessary information to vouch for the end customer’s use of a number.

A typical example is where an interconnected VoIP provider (i.e., VoIP Entity) obtains DIDs from a telephone number service provider and issues these numbers to its customers. The telephone number service provider doesn’t have a fully attestable relationship with the customer, but the VoIP Entity does.

These situation presents difficult problems:

• The VoIP Entity may not be authorized to authenticate calls with SHAKEN. One of the requirements is that the originating service provider has access to numbering resources. The VoIP Entity can originate the call but cannot authenticate them with SHAKEN.
• The VoIP Entity could arrange to have an upstream approved provider sign the calls as a value-add service. But then the signing provider might not be willing to give full attestation. Furthermore, the VoIP Entity would have to send all calls through that one provider, losing the ability to do least cost routing across several upstream providers. This is a difficult business decision for the VoIP Entity.
• End customers want their calls signed with full attestation. They also want affordable phone service. They’re going to have trouble getting that from the VoIP Entity for the reasons listed above.

Toll free calling numbers on outbound calls

Another common variation on this theme is when an enterprise obtains a toll-free number from a Resp Org and uses it for the calling number on outbound calls. In most cases, the OSP is not the Resp Org. The OSP cannot attest that the enterprise has the right to use that number. The Resp Org can.

These difficulties can be overcome with delegate certificates.

Delegate certificates

Delegate certificates extend the triangle of trust, described above, to VoIP Entities that originate calls where the calling numbers were issued by some other telephone number service provider.

Delegate Certificates Extend the Chain of Trust

In this situation, the telephone number service provider issues telephone numbers to the VoIP Entity. The TN service provider knows the VoIP Entity customer, and it knows the numbers.

• In customer-of-customer scenarios, the TN service provider doesn’t know which end customer will get which number.
• In toll-free number scenarios, the Resp Org is the TN service provider but usually is not the OSP. The OSP doesn’t know if the end customer has a right to use that calling number.

Here’s how the missing information is provided.

First, the TN service provider requests an SPC token from the Policy Administrator. This is like the usual process for obtaining an SPC, with an important exception: the SPC token request must include a CA Boolean object set to true. This tells the Policy Administrator that this token will be used to obtain a Subordinate CA certificate.

The Policy Administrator then issues an SPC token, which also contains the CA object set to true.

Having obtained this SPC token, the TN provider then uses it to obtain a Subordinate CA certificate from a SHAKEN Certificate Authority. A Subordinate CA certificate is different from the usual SHAKEN certificates used to sign calls. The Subordinate CA certificate is used only to issue delegate certificates.

Once it has received a Subordinate CA certificate, the TN service provider acts as a subordinate CA and issues a delegate certificate to the VoIP Entity. This delegate certificate lists the telephone numbers that the TN service provider issued to the VoIP Entity. The delegate certificate also establishes a chain of trust from the delegate certificate to the Subordinate CA certificate, to the Certificate Authority root issuing certificate, to the Certificate Authority root certificate.

With the delegate certificate, the VoIP Entity can now authenticate calls for their end customers. The VoIP Entity creates a base PASSporT as an indication that they know the calling party and their association with the calling number. Alternatively, the VoIP Entity could create an RCD PASSporT if they wish to include Rich Call Data. The VoIP Entity cannot use a delegate certificate with a SHAKEN PASSporT.

The terminating service provider will verify call authentication using the base or RCD PASSporT that was signed with the delegate certificate. In addition to the usual verification process, the verification service will verify the scope of the chain of certificates and TNAuthLists to make sure the call information is within the scope of the certificates.

An intermediate SHAKEN-authorized service provider could optionally sign this call with a SHAKEN PASSporT with full attestation, although this is not required. Full attestation would be justified by relying on the base or RCD passport signed with the delegate certificate.

Status of delegate certificates

The ATIS SIP Forum IP-NNI Task Force approved ATIS-1000092, the standards for delegate certificates (opens a ZIP file) on June 30, 2020.

The U.S. STI Governance Authority announced policy changes to support delegate certificates on July 26, 2021.

The U.S. STI-GA announced that the STI Policy Administrator began support for delegate certificates and allowing Resp Orgs to join the SHAKEN ecosystem on October 22, 2021.

TransNexus STIR/SHAKEN solutions

We offer production-ready STIR/SHAKEN solutions in our ClearIP and NexOSS software products. These solutions are unique in their capabilities to combine complete STIR/SHAKEN services with flexible policy controls and a comprehensive portfolio of other services, including fraud prevention, least cost routing and much more.

Contact us today to explore how we can help you implement SHAKEN quickly and easily.