Delegate certificates improve STIR/SHAKEN for providers and enterprises
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 relying partners 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.
There are three defined levels of attestation that can be used by an originating service provider:
- 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.
- 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.
- 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.
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. This 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.
These difficulties can be overcome with delegate certificates.
Our STIR/SHAKEN products:
- Most affordable commercial solutions
- Work with your existing network
- Include support with deployment
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.
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. It just doesn’t know which end customers will get which numbers. Here’s how the missing information is filled in.
First, the TN service provider requests an SPC token from the Policy Administrator. This is is similar to 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 Adminsitrator 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 verfication 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 (opens a ZIP file) standards for delegate certificates on June 30, 2020.
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.
This information will only be used to respond to your inquiry. TransNexus will not share your data with any third parties. We will retain your information for as long as needed to retain a record of your inquiry. For more information about how we use personal data, please see our privacy statement.
TransNexus is a SHAKEN Certificate Authority
We can provide the certificates you need for STIR/SHAKEN.