STIR/SHAKEN authentication service

In the STIR/SHAKEN framework, originating service providers, or carriers who provide gateway authentication services for originating service providers, are responsible for authenticating calls. This paper gives a detailed review of how the authentication service works.

This whitepaper covers the following topics to explain the SHAKEN authentication service:

Attestation
Identity header
Digital signatures

Which calls should be authenticated?

All voice calls that exist on the IP network are expected to be authenticated, whether they:

Originate on the IP network,
Enter the IP network from the public switched telephone network (PSTN), or
Come from an international gateway onto IP network.

STIR/SHAKEN process overview

When a SIP Invite is received from the calling party, the originating service provider sends the SIP Invite to the authentication service in an authentication request.

STIR/SHAKEN call flow

The authentication service checks the asserted caller identity (SIP URI or telephone number) listed in the From header.¹ The service evaluates the legitimacy of the asserted caller identity by determining if the calling party is authorized to use the asserted caller identity.

The criteria for judging the legitimacy of caller identities will vary by service provider, the source of the call, and the network controls in place for various call paths through the provider’s network. These criteria are used to choose an appropriate attestation level for the call.

Even if an attestation is weak, i.e., the provider cannot provide a high level of assurance for a valid use of the caller ID, all parties benefit from authentication and the traceback capability it provides. With STIR/SHAKEN, every call should be authenticated, regardless of the attestation level that can be made.

Along with the attestation level, the originating service provider encodes an Identity Header token and uses it to create a digital signature. These elements are placed in the call by the authentication service and the call is sent on its way. In addition, Out-of-Band SHAKEN can be used to send the Identity token across the internet, around non-SIP call segments.

At the other end of the call path, the terminating service provider uses a companion verification service to check the Identity Header token and digital signature. This process will be described in more detail in a companion whitepaper on the STIR/SHAKEN verification service.

The following sections describe the attestation, identity header and digital signature processes in more detail.

1. Attestation

Originating service providers are responsible for authenticating all calls they originate onto the IP network. However, a service provider may have more confidence in the legitimacy of some caller identities than others. Service providers convey this willingness to vouch for the caller identity by choosing an attestation level for the call:

Full Attestation (A). The originating service provider attests that they are responsible for the origination of the call, that they have an authenticated relationship with the customer making the call, and that they have established a verified association with the telephone number used for the call.
Partial Attestation (B). The originating service provider attests that they are responsible for the origination of the call and that they have an authenticated relationship with the customer making the call. However, they have not established a verified association with the telephone number used for the call.
Gateway Attestation (C). The originating service provider attests that they have placed the call on their network, but they have no relationship with the originator of the call. An example of this case would be a call received from an international gateway.²

The attestation level serves two purposes:

It identifies the originating service provider, which is useful for call traceback. This information can be used by other providers and legal authorities to investigate suspected illegal robocalls or telephone fraud scams.
It indicates the scope of information that the originating service provider will vouch for.

Service providers are expected to stand ready to justify their attestation, especially in traceback situations, so they have an incentive to provide realistic attestation levels.

Origid (origination identifier)

The origid is a unique value that can correspond to a specific customer, class of device, trunk, or other grouping. Assigning an origid can be useful for determining reputation or enabling direct traceback for legal or forensic purposes.

For attestation level B, the origid should point to specific customers or nodes per customer.

For attestation level C, the origid should point to the originating node or trunk to provide the most granularity.

For attestation level A, the origid can be more broadly defined to point to geographic regions or classes of customers since the originating service provider can be held accountable for the caller identity.

2. Identity header

The goal of authentication is to create the Identity header, which contains selected call details from the SIP Invite such as the calling number and the originating service provider’s signature.

The Identity header contains four main parts:

Base-64 encoded PASSporT (Persona Assertion Token) contains information about the call and the signature. Tokens consist of three sections separated by two periods in the form Header.Payload.Signature, where the header and payload sections hold information about the call.
info parameter lists the URL of certificate repository belonging to originating service provider
alg parameter lists the algorithm used to create signature
ppt parameter declares that the token is used for STIR/SHAKEN.

The encoded PASSporT token header and payload can be decoded into a human-readable format to read details about the call:

"header":
"alg": "ES256"
"typ": "passport"
"ppt": "shaken"
"x5u": https://certificates.example.com/123456789.pem
"payload":
"attest": "A"
"dest": { "tn": [ "14695858065" ] }
"iat": 1529071382
"orig": { "tn": "12013776051" }
"origid": "4aec94e2-508c-4c1c-907b-3737bac0a80e" }

The header contents signify that the token was created to be used for STIR/SHAKEN:

The alg and ppt parameters are identical to those found in the Identity header
The typ parameter indicates the token is a PASSporT-type token.
The alg, typ, and ppt values are identical for all SHAKEN PASSporT tokens.
The x5u parameter contains the same URL to the certificate repository as the info parameter.

The payload contains information about the specific call being made:

The attest parameter refers to the attestation level which indicates the originating service provider’s confidence in the caller identity.
The dest parameter indicates the called number provided by the To header.
The iat parameter indicates the exact date and time (in seconds elapsed from 00:00:00 UTC, 1 January 1970) that the PASSporT token was created.
The orig parameter indicates the calling number provided by the From or P-Asserted-Identity header.
The origid header contains a unique identifying number used to trace back the call source.

3. Digital signatures

SHAKEN implements digital signatures to enable service providers to detect and block call spoofing. Digital signatures are created with a hashing algorithm. Hashing is a process that converts a message of arbitrary size into a unique, fixed-size numerical value called a hash value.³ Hashing compresses a message for easier handling.

There are two characteristics of hashing that are important for digital signatures:

Hashing is a one-way method. Although the hashing algorithm describes exactly how to obtain the hash value from the input message, it is impossible to go backwards and determine the original message from the hash value.
Different messages cannot have the same hash value. Different messages must have different hash values. Even if a message is minimally altered by deleting a single comma, the computed hash value of the altered message is completely different from the hash value of the original message. This also makes it more difficult to guess an input to obtain a specific hash value.

An altered message will have a different hash value

To create the digital signature, the authentication service inputs the token header and payload into the hashing algorithm and obtains the hash value.⁴

First, the authentication service hashes the token header and payload

Then the authentication service obtains the originating provider’s private key from the secure key store to create the signature.

The signature is created by a signature generation algorithm, which uses the private key and hash value to create a digital signature unique to the originating provider, token header and payload. This ensures the digital signature cannot be used by a different service provider and cannot be reused later for a different call by any service provider.

The digital signature is then combined with the original token header and payload to create the signed PASSporT token.

Creating digital signature with signature generation algorithm

Signature generated from hashed header, placed in PASSPorT token with original header

With standard In-Band STIR/SHAKEN call authentication, the signed PASSporT token is placed into the Identity header, and the Identity header is returned to the originating service provider. The originating service provider adds the Identity header to the SIP Invite and sends the SIP Invite to the terminating service provider.

With Out-of-Band SHAKEN, the signed PASSporT is sent to their Call Placement Service out-of-band over the internet.

The SIP Invite with the Identity header may pass through intermediary service providers as well. Intermediary service providers are expected to pass along the SIP Invite without altering or removing the Identity header.

Conclusion

The STIR/SHAKEN authentication service enables service providers to authenticate caller identities to mitigate call spoofing. With this service, originating service providers determine an appropriate attestation level, create the signed Identity header and sign the call. These processes then enable the companion verification service to be performed by the terminating service provider.

See our STIR/SHAKEN verification service whitepaper for a detailed overview of this process.

Notes

1. Jon Peterson, et al., “Authenticated Identity Management in the Session Initiation Protocol (SIP),” Internet Engineering Task Force, February 2018 https://datatracker.ietf.org/doc/rfc8224/?include_text=1

2. ATIS, “Joint ATIS/SIP Forum Standard – Signature-Based Handling of Asserted information using toKENs (SHAKEN),” January 2017, https://access.atis.org/higherlogic/ws/public/download/60443/ATIS-1000074.v002.pdf

3. Dan Arias, “Hashing Passwords: One-Way Road to Security,” April 2018, https://auth0.com/blog/hashing-passwords-one-way-road-to-security/

4. Tutorials Point, “Cryptography Digital Signatures,” https://www.tutorialspoint.com/cryptography/cryptography_digital_signatures.htm