STIR-SHAKEN Support

Feature Overview

The proliferation of identity spoofing (potentially combined with robocalling) often leads to unsuspecting consumers falling victim to scams, such as IRS impersonation, offers of free travel, loan support, and software technical support. Identity spoofing and robocalls also devalue the real-time communications process and annoy customers. Well-intentioned, but spoofing techniques easily thwart flawed "blacklists" for anti-robocalling tools and applications. The SBC provides the solution based on industry-standards for securing VoIP call identity.

Secure Telephone Identify Revisited (STIR) defines core protocols and technologies for SIP and the certificate used for applying digital signatures to validate the telephone identity of the calling party. STIR provides an anti-spoofing SIP protocol specification to authenticate a SIP origination using a cryptographic signature which is placed in the Identity header that the terminating SIP element verifies. This identity header provides attribution to the signing carrier, and assurance that it is authorized to sign over the originating telephone number.

Signature-based Handling of Asserted Information Using Tokens (SHAKEN) defines the industry framework for using STIR technologies and how the service providers interwork VoIP-based calls.

Scope of STIR/SHAKEN

Robocalls, spoofing calls, unwanted calls, and spam phone calls are the most significant source of consumer complaints. STIR and Signature-based Handling of Asserted Information Using Tokens is a framework that blocks these calls ensuring Calling Party Information is not spoofed. It authenticates the identity-related information in the call signaling, by generating and verifying the cryptographic signatures, and effectively blocking all Caller ID spoofing and illegal robocalling. SHAKEN/STIR is intended to eliminate the use of illegitimate spoofed numbers from the telephone system by establishing a trust-based system for authenticating legitimate numbers.

STIR/SHAKEN is intended to restore confidence in the authenticity of the origination within SIP interworking elements by providing information to the terminating network. This is used to communicate to the user with assurances that include whether the calling party is legitimate, such as the signature included in the SIP invite is valid and was created by an entity with authority to attest to the originating telephone number. STIR/SHAKEN implementation is one component in the overall strategy to provide customer value to address anti-spoofing and robocalling mitigation techniques. This deployment of STIR/SHAKEN may reduce timeframes and resources for traceback associated with identifying the source of illegal and unwanted robocalls.

The scope of STIR/SHAKEN planned deployments that include SIP capable networks include

• VoLTE Retail and Wholesale (MVNO where technically possible)
• VoIP Peering traffic (Direct, Indirect, and Internal)
• CDMA originations to Peers (Direct, Indirect, and Internal)   
• FiOS Digital Voice (FDV)  
• Enterprise VOIP  
• VoIP Wholesale (Pass-through and Identity Provided)

The IETF STIR and ATIS/SHAKEN specifically support:

• The validation of incoming calls to the subscriber networks, which contain a cryptographic signature, that includes the future visibility of the signature validation status to the subscribers. This validation permits users to make informed decisions and enable network and customer analytics.
• The signing of legitimate calls originating on the networks, permitting the downstream authentication through cryptographic signature utilizing the STIR/SHAKEN framework (in a phased approach where technically possible)
• A STIR/SHAKEN compliant transit path that supports the transport of a cryptographic signature across trust boundaries, allowing the user to serve as an enabler to adoption within the service provider ecosystem

Call Flow

The SBC supports the following STIR/SHAKEN functionalities:

• Pass-through of STIR/SHAKEN information: Based on the provisioning, the SBC passes STI-related information without any modification.
• Removal of STIR/SHAKEN information: Based on the provisioning, the SBC removes STI-related information.
• Local tagging: Tagging is not a cryptographic operation and hence does not require access to private key and signing, which the SBC and the PSX achieves.
• Signing through the Ribbon STI-AS: The STI-AS generates a signature over specific identity-related SIP headers by using the operator's private key. The SBC/PSX communicates with this entity through HTTP(S)/JSON-based on the JSON schema as ATIS defines. The SBC generates the Identity header based on the received signature.
• Verification of signature through the Ribbon STI-VS: The STI-VS verifies the signature received in the Identity header by using the signing operator's public key. The SBC/PSX communicate with this entity through HTTP(S)/JSON-based on the JSON schema, as defined by ATIS. SBC adds the verstat parameter that indicates the result of verification based on the received response.

• Support for SIP signaling enhancements: The SBC generates and parses new STI headers and supports passthrough/mapping of STIR related response codes. 

STIR/SHAKEN Call Flows

Header/Parameter Content Strategy

Information received from PSX per route during signing:

• Service Type: Signing
• Service Status: Success/Failure
• Reason Code
• Reason Text 
• Identity header information in full form
• P-Origination-Id
• An Indication to send (in the egress signal) received values of the following:
• Identity headers
• P-Attestation-Indicator
• P-Origination-ID
• verstat parameter

Information received from PSX per route during verification:

• Service Type: Verification
• Service Status: Success/Failure
• Reason Code
• Reason Text
• verstat
• An Indication to add verstat parameter either to From or to PAI header
• An Indication to send (in the egress signal), received Identity headers.

Information received from the PSX per route during tagging:

• Service Type: Tagging
• Service Status: Success/Failure 
• P-Origination-ID
• P-Attestation-Indicator
• verstat
• An Indication to add verstat parameter either to From or to PAI header

The SBC generates and parses the following new headers:

• Identity Headers
• P-Origination-ID
• P-Attestation-Indicator
• verstat parameter

New information sent over Gateway-Gateway signaling:

• Service Type: Signing/Verification/Tagging
• Service Status: Success/Failure 
• Identity Headers
• P-Origination-ID
• P-Attestation-Indicator
• verstat parameter
• Reason Code and Text

Error Handling Strategy

Error handling-related policy resides in the PSX for errors generated during interaction with Signing/Verification Server. The PSX conveys error handling decision in D+ reply, and the SBC follows the corresponding semantics as applicable. Error handling policy for SIP response codes is configured in the SBC. The SBC increments the 4XX statistics for SIP errors and logs the STI Service Type, STI Service Status, STI Reason Code and Origination ID in CDR fields.

Handling of Errors for STI-AS/VS Procedures

When STI-AS/VS server is performing STIR/SHAKEN-related procedures in the context of relevant semantics, certain error conditions are encountered. These conditions are detected and reported by the server.

Signing Request Error

The SBC supports the following error conditions:

• The date information supplied to the server is considered “stale” by the server.
• Internal server error encountered during signature generation; HTTP 500 response received from the Server.
• Server not available to handle the signing request.

Verification Request Error

The SBC supports the following error conditions:

• The date information received in INVITE is considered "stale" according to the server response.
• The  “identity-digest” value is malformed according to the server response.
• PPT value is not “SHAKEN” and the server supports only “SHAKEN” according to server response.
• “Info” parameter missing in “identity” according to server response.
• “Info” parameter from “identity” is invalid because it is a syntactically invalid URI according to server reply.
• Dereferencing of URI from “info” failed according to the server response.
• PASSporT header is missing [“ppt/”typ”/”alg”/”x5u”] claim according to the server response.
• PASSporT header “x5u” value does not match the “info” parameter from “identity” according to the server response.
• "typ" from PASSporT header is not "passport" according to the server response.
• "alg" from PASSporT header is not "ES256" or "RS256" and the server supports only these according to the server response.
• "ppt" from PASSporT header is not "SHAKEN" and only this the server supports according to Server reply.
• [ "dest" / "orig" / "attest" / "origid"] claim missing in PASSporT payload according to the server response.
• "iat" from PASSporT payload is stale according to the server response.
• ["orig" / "dest" / "mky"] claim from PASSporT payload does not match that received in the verification request according to server reply.
• Certificate Authority verification failed according to the server response.
• Signature validation failed according to the server response.
• Missing SHAKEN extension "attest" claim in the decrypted PASSporT according to the server response.
• Missing SHAKEN extension "origid" claim in the decrypted PASSporT according to Server response.
• ["orig" / "dest" / "mky"] claim from decrypted payload does not match that received in the verification request according to the server response.
• "iat" claim from decrypted payload doesn’t match "iat" from PASSporT payload according to server response.
• Internal server error encountered during signature generation, HTTP 500 response received from the server.
• The server is not available to handle the signing request.

The PSX maps the error indication to a response code and reason text and communicates to the SBC in D+ response.

Handling of errors for STI-AS/VS procedures

Handling of Receipt of SIP Error Responses From Downstream Entity

The SBC treats the STIR-related SIP response codes as follows:

• 428 (Use Identity header): The SBC supports up to four identity headers to send their contents to the PSX as part of the D+ query and receive/process the corresponding D+ reply. This means Identity header, which was expected, but was not received by a downstream entity. The reason probably due to a misconfiguration in the PSX  or some downstream network element or a problem with the partner agreements. This does not require special processing.
• 436 (Bad Identity information): Downstream entity was unable to retrieve credentials to validate Identity header. The possible reasons could be a network problem, a wrong configuration in the signing server. This does not require special processing.
• 437 (Unsupported credential): Credentials not supported by the downstream entity. The possible reasons could be a non-valid certificate, unsupported signing algorithm. This does not require special processing.
• 438 (Invalid Identity Header): Signature verification failed. The reasons could be a bug/malfunction during signing/verification or tampering of Identity/Identity-related information. This does not require special processing. The SBC may receive 438 SIP error response for cases where the SBC receives and relays Identity header generated by an upstream entity and yjr downstream verifier generates the 438 error response during verification of this Identity header. The SBC relays 438 error response and the upstream entity, which inserted the Identity header, may/may not retry the request with Identity generated in full form.

The SBC may also receive the response code if it uses a compact form of Identity header and the downstream entity performing verification expects the full form. Therefore, the request should be resent with full form Identity header. 

In this phase, The SBC supports only the “SHAKEN” claim set for which the full form is mandated. The SBC always sends the Identity header in full form; therefore, this error response is not applicable. The SBC relays 438 error response to upstream entity. 

If the SBC receives Identity header in compact form and full form is required, it generates 438 SIP error response to check if it requires the full form for a received identity header. STI-AS/VS determines its enforcement and the SBC generate 438 error response based on the verification result received from STI-AS/VS.

• 403 (some Reason-Phrase): The Date header value is too old, or it is populated wrong or has a bug in the downstream element. For example, it enforces a too short of a limit. No special processing is needed.
• 403 received for an INVITE with Identity header is treated as indicating “stale Date header”. The SBC cannot rely on reason-phrase to distinguish between 403 sent for another reason against the 403.sent for “state Date header” as there is no MUST level mandate in RFC 8224 to use a specific Reason-Phrase.

For each error response, either a “retry without Identity”, “fail the call”, “try next route” is configured, if applicable. The SBCapplies this configured behavior for 438 only after the special behavior of retry with full Identity header if available is executed, once the functionality for using compact form is supported (Deferred). SIP error response treatment policy is present  in the SBC.

The proliferation of identity spoofing (potentially combined with robocalling) often leads to unsuspecting consumers falling victim to scams, such as IRS impersonation, offers of free travel, loan support and software technical support. Identity spoofing and robocalls also devalue the real-time communications process and annoy customers. Well-intentioned, but spoofing techniques easily thwart flawed "blacklists" for anti-robocalling tools and applications. The SBC provides the solution based on industry-standards for securing VoIP call identity.