Complete Guide to Deploy STIR/SHAKEN

In this article, we highlight the essential steps required for Service Providers in the United States to deploy STIR/SHAKEN framework. Service Providers must deploy the STIR/SHAKEN framework for compliance with the TRACED Act. The guide covers a spectrum of technical and non-technical steps necessary for successful deployment of STIR/SHAKEN. With this guide, Service Providers will have a full picture of all the steps required to become compliant. If you are further along in your journey we recommend the following articles:

• STI-PA Approval Phase
• Three Steps to Obtain a Certificate

This document is outlined in phases as illustrated below:

 STIR/SHAKEN in the United States operates within a governed ecosystem, overseen and regulated by iconectiv as the STI-PA (Policy Administrator). In this role, the STI-PA governs Service Providers (SPs) and Certificate Authorities (CAs). All Service Providers and Certificate Authorities must first receive approval from the STI-PA to participate in the ecosystem.

Pre-Requisites

To register with the STI-PA, Service Providers must meet the following pre-requisites:

NECA OCN

Have an Operating Company Number (OCN). OCNs are assigned by the National Exchange Carrier Association (NECA).  Obtaining an OCN can take anywhere from 3-10 business days depending on the procedure path you choose. The cost of obtaining an OCN ranges from $550 to $675.

• Here's the link to start the process with NECA: https://www.neca.org/business-solutions/company-codes 
• This is the form that must be submitted to NECA: https://www.neca.org/docs/default-source/public---business-solutions/code-administration/company-code-request-form---0923.pdf?sfvrsn=4f82ff1b_19

FCC 499A

The FCC Form 499-A, is a form required by the Federal Communications Commission (FCC) in the United States. It is used for reporting annual revenue information by telecommunications carriers, interconnected Voice over Internet Protocol (VoIP) providers, and certain other providers of telecommunications services. Service Providers must have an up to date 499-A form on file with the FCC to participate in STIR/SHAKEN.

Robocall Mitigation Database (RMD) Filing

The FCC requires that all voice service providers certify in the Robocall Mitigation Database that they have fully implemented STIR/SHAKEN and have instituted a robocall mitigation program to ensure that they are not originating illegal robocalls.

STI-PA Registration

Registration Phase

Having met the above requirements you can start the Service Provider registration here: https://authenticatereg.iconectiv.com/register

In general here are the different phases to complete the registration process with iconectiv:

1. Complete registration
2. Complete readiness evaluation testing. Sansay is an iconectiv approved vendor which means Service Providers using Sansay's STI solutions can get directly on-boarded to the STI-PA's production environment bypassing the staging environment.
3. Obtain Service Provider account credentials
4. Submit user agreement and provide billing information
5. Account activated

After step 5 you can proceed to obtain a STIR/SHAKEN Certificate with an approved Certificate Authority (STI-CA) including Sansay. Before a STIR/SHAKEN certificate is issued you must first obtain an SPC Token. The STI-PA provides API for this. By providing Sansay with STI-PA API credentials our STI-CA portal can issue the SPC Token on your behalf.

The STI-PA outlines the registration process in detail in this document: https://authenticate.iconectiv.com/sites/authenticate/files/2021-10/Service_Provider_Guidelines_Issue_6.pdf

Per the STI-PA documentation the registration process can be completed in a minimum of 3 business days.

Approval Phase

Once the STI-PA has vetted your application, they will send you a request for additional information similar to the illustration below. A key part of this step is to inform the STI-PA that you are working with Sansay as your vendor (when using Sansay for call signing). This will allow you to move to production environment and bypass the staging and evaluation test plan as Sansay has already completed this for our customers.

Production Environment Form

Here are some of the questions the STI-PA asks that you may need guidance with:

1. Are you planning to use any other OCNs when requesting SPC Tokens? While only one OCN is required to obtain one SPC token, if your organization has more than one OCN we recommend the following approaches:
   1. Applying for a second SPC with an alternate OCN to serve as a backup SPC token. The SPC token is what ultimately gets you a certificate. In this case, the backup OCN can be viewed as a backup certificate.
   2. Use your OCN for different types of traffic. You may have different types of traffic in your network with varying trust. You could take advantage of your multiple-OCNs and obtain SPC tokens that will be used to sign different types of traffic (e.g. retail uses one OCN, SIP trunking uses a different OCN, etc). Please note that telephone numbers/ANIs are not tied to a specific OCN in the STIR/SHAKEN ecosystem.
2. SPC Token Expiry timer value.  We recommend 14 days.
3. Are you working with an approved STI-PA software vendor? Yes, tell them that you are working with Sansay.
4. Please provide your IP addresses for whitelisting in both the Staging and Production environments.
   1. The Web Portal access sections will be used to access the GUI. The GUI is used for registration, user management, and uploading revoked certificates. At a bare minimum, you will want to have the IP addresses of your administrator(s), and any billing personal whitelisted. Another approach is to request whitelisting your corporate network/VPN address.
   2. The API section is for the IP’s of the machine(s) that you will be calling into the STI-PA with in order to request tokens and other functions of the system.  This will be the IP of your Sansay NSS IP address(es) or your STIR/SHAKEN as a Service (SS/aaS) hosted solution provided by Sansay. If you do not have this yet will you need to start this step ASAP.

iconectiv/STI-PA  can accommodate multiple IP addresses, ranges, and subnets to fit your business needs. Also, if your network has any IPv6 active, please include those address(es) as well.

Selecting a Certificate Authority (STI-CA)

After the STI-PA has activated your account you can proceed to choose the Certificate Authority (STI-CA) that will issue your STIR/SHAKEN certificate(s). Certificate Authorities will verify your STI-PA eligibility to obtain a certificate by the means of an SPC token. By providing Sansay with STI-PA API credentials our STI-CA portal can issue the SPC Token on your behalf.

When selecting a STI-CA you will want to consider the following factors:

• Certificate acquisition methods. Manual or automated. Sansay STI-CA offers manual or automated renewals. For automated renewals we run an standards-based ACME server as defined in ATIS-1000080.
• Certificate lifetime choices. Number of days the certificate will be valid for. Sansay STI-CA provides flexible lifetime from 1-365 days.
• Certificate repository. When a call is signed a public URL of the signing certificate is included in the STIR/SHAKEN signature. This function is known as certificate repository (STI-CR). Sansay STI-CA provides highly available STI-CR infrastructure to host your certificate.
• Cost to obtain a certificate. Sansay STI-CA offers a flat-fee to obtain certificates for your subscribed period. The cost of certificates is based on the # of SPC codes you need covered.
• Cost to renew a certificate. Sansay STI-CA provides unlimited certificate renewals under the cost of your certificate subscription.
• Cost to re-key a certificate. Sansay STI-CA provides unlimited certificate re-keys to ensure the integrity of your certificate.
• Technical support. Sansay provides unlimited support to help you manage the lifecycle of your certificate.

Obtaining a STIR/SHAKEN Certificate

Obtaining a STIR/SHAKEN certificate with Sansay STI-CA is an easy process. The Sansay STI-CA web portal is the hub for certificate managmenet including tools to 1) Create Private Keys and CSRs 2) Issue Certificates 3) Grant access for automated renewals.

This article illustrates the three simple steps to obtain a STIR/SHAKEN certificate using Sansay STI-CA web portal.

Pre-requisites:

• Approval from STI-PA. Related article: Working with the STI-PA https://support.sansay.com/t/p8hlsht/working-with-the-sti-pa#approval-phase
• STI-PA API User creation: https://support.sansay.com/t/y4hz3jc#sti-pa-api-user

STI-CA Web Portal

After completing registration with the STI-PA and creating an API user, Sansay Support will create an STI-CA account on Sansay's web portal. Here are the three steps to obtain your certificate.

Here are the above steps in action described in this video:

For more information please go to this article: Three Steps to Obtain your STIR/SHAKEN Certificate.

Signing Calls with a STIR/SHAKEN Certificate

Signing platform

To be able to sign calls using the STIR/SHAKEN framework, a Service Provider must have a STIR/SHAKEN certificate from an approved STI-CA.  The signing platform will influence the following factors:

• Certificate lifecycle management. Will the certificate be issued on-demand/manually or automatically? Some solutions support automated certificate renewal using the ATIS backed ACME spec as defined in ATIS-1000080 (https://cstga.ca/wp-content/uploads/2020/07/ATIS-1000080.v002_SHAKEN-Governance-Model.pdf). Automated certificate renewals have the benefit of reduced overhead (renewing certificates). Other solutions will require manually updating a certificate from time to time (e.g. every year).
• Signing process. Based on the switching platform's capabilities the signing process most typically takes place over SIP or REST interfaces. Some switching platforms are capable of also signing a call. For simplicity this article covers the switching and call signing functionalities separate. 

Sansay supports all STI-CA call signing platforms including Sansay NSS.

• Sansay NSS. A Service Provider using Sansay's Network-operator STIR/SHAKEN solution (NSS) can opt for on-demand or automated certificate issuance and renewal options. Sansay NSS can be deployed in the cloud or on your premises.
• 3rd-party platforms. Service Providers using Sansay STI-CA may also rely on 3rd-party signing platofmrs to sign calls. Please check with your vendor of choice on the process to load a STIR/SHAKEN certificate. In general STIR/SHAKEN signing platforms will require: 1) a private key to import, 2)  a public certificate URL generated by the STI-CA when issuing the certificate.

Once your signing platform is configured you are ready to start testing STIR/SHAKEN call signature.

STIR/SHAKEN in a Nutshell

STIR/SHAKEN utilizes cryptography to authenticate and verify caller ID information. It involves the use of digital signatures, certificates, and cryptographic keys to ensure the integrity of a call. It all starts at an Originating Service Provider (OSP) signing a call with a digital signature using a STIR/SHAKEN certificate obtained from a STI-CA. . The digital signature that contains information about the call including the originating telephone number (origTN), the terminating telephone number (destTN), the time the call was made (iat), the certificate URL for verification purposes and the attestation level the call is given. This digital signature is carried in the form of the SIP Identity header.

The call signing process consists of the following elements:

• Switching platform (SBC, PBX, Switch). This platform processes calls originated in the network. This process usually takes place at the Originating Service Provider (OSP). 
• Signing platform. Takes the details of the call via a query (SIP or REST) and create the SHAKEN PASSPorT. The STIR/SHAKEN PASSPorT is the encoded digital signature carried by the SIP Identity header. The signing platform can be internal or external to the switching platform. Sansay's approach is an external platform where the switching platform obtains the SHAKEN PASSPorT via a query.
• Verification platform. Takes a digital signature, the call details and verifies its authenticity. This process usually takes place at the Terminating Service Provider (TSP).  

Once the digital signature is generated, which is known as the SHAKEN PASSPorT, it's the switching platform's job to deliver signed traffic leaving the Originating Service Provider's network with the SIP Identity header. As the call transits the network the responsibility of carrying the SIP Identity header is relayed to underlying carriers all the way to terminating Service Provider (TSP).

Testing

Testing call signing consists in making sure the SIP Identity header obtained is deliver end-to-end: from the Originating Service Provider (OSP) making the call, to transit/underlying carriers, to the the Terminating Service Provider (TSP) verifying and delivery the call.  As the call transits the network the Identity header may be dropped, replaced or SIP headers may be modified in a way that no longer matches the original signature. Making the necessary tests will ensure expected results.

Suggested tests

We recommend considering the following tests:

• Standard call origination.
• Test all underlying/downstream carriers (ULCs) if applicable.
• Call forward.
• Emergency calls and special services.
• Anonymous calls.
• Calls with Rich Call Data (RCD), if applicable.
• Cross-border SHAKEN (e.g. US to Canada).

Sansay maintains a free STIR/SHAKEN Test Environment for theses purposes. The test environment will allow a caller to verify the details of a call as it traverses the phone network.

More details on Sansay's test environment and alternate numbers are available here: https://support.sansay.com/t/y4hw8a0/stirshaken-test-number

Production

After completing the initial tests to expand the scope of call signing and finalize your STIR/SHAKEN implementation.

Metrics

We recommend monitoring the following metrics to quantify your STIR/SHAKEN implementation.

• Total calls originated in the network.
• Total calls that obtained a STIR/SHAKEN signature.
• Total calls that failed to obtain a signature.
• Total calls attestation levels (A, B, C).
• PDD (if using an external call signing platform).
• If you are a transit provider, total calls that arrived with a STIR/SHAKEN signature.

Sansay NSS solution includes these metrics and the ability to alert or generate reports automatically or on-demand.

Certificate Renewal

Of extreme importance is to ensure that your STIR/SHAKEN certificate is always valid. Please ensure that you have mechanisms to identify of an upcoming certificate expiration and in the case of automated renewals be alerted of any issues with the renewal process.

Update FCC Robocall Mitigation Plan

If your original FCC Robocall Mitigation Plan Filing did not include full implementation of STIR/SHAKEN please submit an updated mitigation plan to reflect your network's capabilities.