Update to SHAKEN standard on forwarded and diverted calls

The SHAKEN standards are changing for calls that are diverted by features such as call forwarding. This blog post briefly explains how this brings the benefits of SHAKEN authentication to diverted calls, and what’s changed in this new version of the standards.

Call diversion

There are common scenarios where calls are diverted:

• The called party has forwarded his/her calls to another phone number.
• The called party has enabled a call feature to have incoming calls ring simultaneously on other telephones.
• The called number is an 8YY number, which will be translated to an actual assigned number used by the called party.
• The called number is a URN (Uniform Resource Name), such as 911 for emergency calls, which will be translated to an actual assigned number for the called party.

These scenarios would cause problems for basic SHAKEN as described in ATIS-1000074. Here’s why.

Call diversion and SHAKEN

The SHAKEN PASSporT includes both the calling and called number. This prevents the SHAKEN token from being intercepted and reused by a bad actor making spoofed calls to other called numbers. The terminating service provider checks the calling and called numbers as part of the verification process.

But when a call is diverted, the called number in the PASSporT wouldn’t match the diversion phone number. SHAKEN verification would fail.

DIV PASSporT to the rescue

The DIV PASSporT solves this problem. When a service provider diverts a call to another number, they add a DIV PASSporT to the call. This creates a chain of authentication. The terminating service provider verifies the caller ID using both the SHAKEN and DIV PASSporTs.

SHAKEN Call Flow With a Diverted Call

The SHAKEN DIV standard

The primary change to the standard under consideration is to include support for URN (Uniform Resource Name) for emergency and other well-known services, as described in RFC 5031. For example, in the U.S., this enables end-to-end call authentication on emergency calls to 911, calls to the 988 suicide prevention hotline, and so forth.

The standards document also now clarifies the implied attestation for the retargeted called number. Since the DIV PASSporT does not contain an attestation level, verifiers must assume that the diversion carries the equivalent of a full attestation. For example, in the SHAKEN call flow diagram above, Service Provider B:

1. Is responsible for the origination of the retargeted call onto the telephone network,
2. Must have a direct authenticated relationship with the retargeting customer and can identify the customer,
3. Must have established a verified association with the retargeting telephone number.

In order to fulfill these assumptions, service providers should vet customers for whom they provide diversion service and include strong penalties for bad behavior in the terms and conditions of service.

(Updates: the updated DIV standard, ATIS-1000085.v002, has since been published. ATIS-1000098, a standard on resource priority headers in emergency calls, has also been published.)

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.