Attestation Under Stir/Shaken
STIR/SHAKEN requires service providers to attest or sign every call passing through their network. This involves certification that the service provider is satisfied to some degree of the caller’s identity.
Three Levels of Attestation
There are three different levels of attestation. The type of attestation depends on which network a call originated in.
Full Attestation (“A” Attestation)
The service provider knows the customer's right to use the phone number.
"A" attestation indicates that the service provider has verified the caller's identity and that the subscriber is using its actual telephone number. The service provider thus has the highest level of confidence in the caller.
Partial Attestation (“B” Attestation)
The service provider knows the customer but not the source of the phone number. The service provider is unsure if the customer is legitimately spoofing the number.
The originating carrier has no verifiable relationship with the phone number.
Gateway Attestation ("C" Attestation)
The service provider has originated the call onto the network but can't authenticate the call source. For example, the call has been placed through an international gateway or originated in a domestic network that has yet to be STIR/SHAKEN enabled.
These are typically calls that don't satisfy A and B attestation requirements.
The service providers can ascertain where the call came from but can't authenticate the caller ID or the caller's right to use the originating phone number.
Full Attestation Challenges – the Problem Outlined
It is essential for enterprises that their calls are given an "A" attestation. However, there is no guarantee that this will happen.
It may happen that a service provider does not have the necessary information necessary to fully attest a call. For instance, take a scenario in which a DID reseller obtains direct inward dial numbers (DIDs) from a telephone number service provider and issues these numbers to its customers. In this instance, although the DID reseller entity has a direct fully attestable relationship with the customer, the telephone number service provider does not.
This scenario presents some challenges to the provision of Full “A” Certification:
Firstly, the DID reseller can originate the call, but may not be able to authenticate the call with SHAKEN since it may not have access to numbering resources, which is a requirement.
Secondly, although it would be possible to utilize the services of an upstream approved provider to sign the calls, the signing provider might only be prepared to give B attestation.
Thirdly, this “solution” would prevent the provision of a least cost routing service since all calls would need to be sent through the single upstream provider.
Customers need two things – firstly they require Full A Attestation and secondly, they require cheap calls using least cost routing. In this scenario, neither need can effectively be met.
Is there a solution to this conundrum?
Delegate Certificates – What Are They?
Delegate certificates have been designed to cater for this type of challenge.
Delegate Certificates, sometimes called Identity Certs or Enterprise Certs, have been authorized to cover a scenario in which the provider that issued the number doesn't know the end customer who was ultimately assigned the number and so cannot give an "A" attestation.
Since the 3rd party that issued the number can attest to knowing the end customer. The third-party is authorized to issue a delegate certificate to the end customer, which can then provide a full "A" attestation.
For example, delegate certificates can be used by end customers that originate calls where some other telephone number service provider issued the calling numbers as in the example provided above.
Another example is where a Resp org issues a toll-free number. In such a case, the Resp org is the TN service provider but is not the party originating the outbound calls. The Resp org issues a delegate certificate to verify it knows the end customer.
The issue of delegate certificates facilitates the confirmation of full "A" attestation in areas that would not usually result in the full attestation.
How do Delegate Certificates Work?
Let’s use the example in which the TNSP ( Telephone Number Service Provider ) has issued telephone numbers to a DID reseller. In this instance, the TNSP knows the DID reseller as well as the numbers but has no idea which numbers will be given to which end users. This is how delegate certificates are used to cover the gap so to speak:
Step 1 – TNSP requests a CA certificate from the CA.
Step 2 – TNSP issues a delegate certificate to the DID reseller once the TNSP has received the CA certificate. The delegate certificate lists all telephone numbers issued to the DID reseller by the TNSP.
Step 3 – the DID reseller now uses the delegate certificate to authenticate calls for its end customers. Note that the DID reseller cannot use a delegate certificate with a SHAKEN PASSporT, however, the DID reseller can now do one of two things.
Firstly, it could create a base PASSporT which signifies that the reseller knows the calling party and the association with the calling number.
Secondly, if the DID needs to include RCD, then it would create a RCD PASSporT.
Step 4 – The base or RCD passport is then used by the terminating service provider to verify call authentication. The delegate certificate also establishes a chain of trust between delegate certificate, subordinate CA certificates, Certificate Authority root issuing certificates and Certificate Authority root certificates.
Delegate Certificates and RespOrgs
Robocallers often use toll free telephone numbers owned by reputable entities to spoof the end user into answering the call.
This has necessitated authentication of toll-free numbers
The FCC has determined that only the RespOrg associated with a specific toll-free number can authenticate the identity of the subscriber associated with a specific number. Only the RespOrg can provide an A-level certification for such calls.
Where the RespOrg is not also the carrier, and is simply a number broker, the challenge of certification arises.
Again, the solution is to use delegate certificates to allow for full “A” authentication by non-carrier RespOrgs.
Note however, that this is optional. Toll free subscribers that display toll free numbers in the caller ID field should discuss call authentication with their RespOrg.
Flow of Information in Delegate Certificate Scenarios
In both scenarios outlined above, there is missing information which prevents the granting of Full “A” Attestation:
In the Resp Org scenario, where the TNSP is simply selling DIDs to a toll free number reseller, the TNSP has no idea whether the end customer has a right to use the number.
In a customer of customer scenario, the TNSP is unaware which customers will be given which numbers.
The Technical Information Flow Explained
So exactly how is the missing information provided to the TNSP, so that “Full A” Attestation can be granted?
It goes something like this:
Step One
TNSP requests an SPC Token from the Policy Administrator. This differs from the normal SPC Token process in that the CA Boolean object in the token request is set to TRUE, indicating to the Policy Administrator that a subordinate CA certificate is requested.
Step Two
The TNSP submits the SPC Token to a SHAKEN CA which then issues a Subordinate CA Certificate to the TNSP.
Step Three
The TNSP, acting as a subordinate CA, uses the Subordinate CA Certificate to issue a Delegate Certificate to the TNSP. The Delegate Certificate contains a list of the telephone numbers issued by the TNSP to the DID reseller. The integrity of trust is maintained between all the certificates in the chain.
Step Four
The DID reseller now uses the Delegate Certificate to authenticate calls for its customers. The DID reseller achieves this by issuing what is known as a base PASSporT which indicates that the DID reseller knows the calling party can attest to its association with the calling number.
If the DID reseller elects to include RCD, then it could issue an RCD PASSporT.
At this stage, the TNSP uses the base or RCD PASSport to verify call authentication using the base or RCD PASSporT. The scope of the chain of certificates and TNAuthLists are also verified at this point to ensure that the call information falls within the certificate scopes.
In Summary
STIR/SHAKEN architecture has evolved one step further by facilitating the issue of full "A" attestation in circumstances in which full "A" certification should have been issued but required 3rd parties to validate the numbers and then pass this information on to the service provider.
Peeringhub is a Stir/Shaken CA and supports the issuing of delegate certificates to Service Providers and Resporgs. We also provide tools for our subordinate CAs to issue certificates to their end customers. Please visit www.peeringhub.io for more information.
0 Comments