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:
STIR/SHAKEN Call Flows
Header/Parameter Content Strategy
During the initial processing of a message, the SBC is not aware of the STIR/SHAKEN procedures applied at the PSX. Hence, the
sends the following STI-related information elements, if received, to the PSX. The state of the
stiProfile associated with the trunk group has to be enabled for
to apply STI mechanisms.
- Identity Headers
- P-Origination-ID
- P-Attestation-Indicator
- verstat parameter
- To URI
- From URI
- PAI URI
- Current Time (determined by SBXthe SBC)
- SDP Fingerprint information
SHAKEN always uses the full form of the Identity header; therefore the SBC supports only the full form of the Identity header. For signing and verification of the full form of the identity header, the PSX sends the current time determined by
and not the Date header information to the STI server. Hence, the
neither processes nor sends the Date header natively. If you need to pass the Date Header transparently, use the
’s Header Transparency feature.
| Info |
|---|
| Signature verification failure may occur if the /PSX is configured to apply ingress or egress modifications to STIR/SHAKEN related information. |
Information received Information received from the 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 Information received from the 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.values of the following:
- Identity headers
- P-Attestation-Indicator
- P-Origination-ID
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
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
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
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 in D+ response.
Handling of errors for STI-AS/VS procedures
Handling of Receipt of SIP Error Responses From Downstream Entity
The
treats the STIR-related SIP response codes as follows:
- 428 (Use Identity header): The 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 may receive 438 SIP error response for cases where the 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
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
supports only the “SHAKEN” claim set for which the full form is mandated. The
always sends the Identity header in full form; therefore, this error response is not applicable. The
relays 438 error response to upstream entity.
If the
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
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 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
applies 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
.
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
provides the solution based on industry-standards for securing VoIP call identity.