Teraquant 'No Fluff' Blog

As part of Oracle’s continued deep investment into OCOM/EOM, release 6 has some very nice features which we shall be highlighting over the next few weeks.

My favorite from this latest batch is the analysis of STIR/SHAKEN. Here OCOM/EOM analyses the HTTPS request northbound from the SBC as well as the SIP headers.

This is interesting because it gives one a little clue as to where Oracle might be going with future developments on OCOM/EOM despite never publishing a roadmap.

Note: this link is always TLS encrypted, so use your SBC to decrypt this HTTPS leg or talk to Teraquant about a decryption tap.

If you have an Oracle SBC, use that as a probe to pipe the captured packets directly to your OCOM/EOM mediation engine.

You can then troubleshoot the connection with your Authenticating Service (STI-AS) and STI-Verification Server (STI-VS) services.

Technical benefits include being able to check that the Signing Response inserted in the SIP header directly corresponds to the information coming from your STI-AS and STI-VS

This extensive functionality in OCOM/EOM allows you to filter on all the important S/S headers to isolate your issue at hand.

Here’s a refresher on all the key S/S headers so you know what to filter in using OCOM/EOM

The Identity Header contains the S/S Token called the PASSporT which tells you which call is being certified and where to get the certificate for verification.

PASSporT Payload: Contains the actual call claims, including:

• orig: The calling telephone number.
• dest: The destination (called) telephone number(s).
• iat: The “issued-at” timestamp (Unix time).
• attest: The attestation level (A, B, or C).
• origid: A unique ID for traceback.

As well as the PASSporT, the SIP Identity header contains the following supplementary information:

• info: Repeats the URL link to the certificate (matching the x5u in the PASSporT).
• alg: Repeats the algorithm (ES256).
• ppt: repeats the extension type (shaken).

Sample Plain Text Header
{

“alg”: “ES256”,
“ppt”: “shaken”,
“typ”: “passport”,
“x5u”: “https://certificates.clearip.com/b15d7cc9-0f26-46c2-83ea-a3e63a82ec3a/7cc4db695d13edada4d1f9861b9b80fe.crt”

}

Sample Plain text Payload

“attest”: “A”
“dest”: { “tn”: [ “7654423282 ” ] }
“iat”: 1529071382
“orig”: { “tn”: ” 8609653208 ” }
“origid”: “4aec94e2-508c-4c1c-907b-3737bac0a80e” }

The P-Identity-Bypass header is a specialized SIP header used primarily in Europe (specifically in France) to manage the “disengagement” or exclusion of a call from the standard STIR/SHAKEN signing process.

• Instruction to Ignore Identity: If a SIP INVITE contains both an Identity header and a P-Identity-Bypass header, the bypass header serves as an instruction to downstream operators to ignore the Identity header entirely.
• We don’t use P-Identity-Bypass in North America

The S/S Certificate certifies the identity of the originating service provider (the carrier) and their right to participate in the trusted STIR/SHAKEN ecosystem.

The Payload of the PASSporT Contains the actual call claims, including:

• orig: The calling telephone number.
• dest: The destination (called) telephone number(s).
• iat: The “issued-at” timestamp (Unix time).
• attest: The attestation level (A, strong, or C).
• origid: A unique ID for traceback.

The PASSporT (Personal Assertion Token) within the Identity header contains the attestation. But this can also be filtered on specifically using this filter

Similarly there is a shorthand to filter on the origid

Once the call has traversed the network from the originating carrier, on reaching the terminating carrier, their SBC needs to verify 3 things which are displayed in clear readable format in the received SIP INVITE in the Verstat.

the 3 things the Verstat shows are:

1. Signature Validity: It confirms that the digital signature in the PASSporT has not been tampered with and was signed by a legitimate certificate authority.
2. Number Authenticity: It verifies that the “From” number in the SIP INVITE matches the number contained inside the encrypted PASSporT payload.
3. Trust (Attestation) Level: It conveys the level of confidence (A, B, or C) that the originating carrier has in the caller’s right to use that number.

Sample API response from STI- VS to SBC

• HTTP/1.1 200 OK
• X-Span-ID: ..
• Content-Type: application/json
• Date: …
• X-Msw-Message-ID:
{
“verificationResponse”:{
“attest”: “A”
“origid”: “4aec94e2-508c-4c1c-907b-3737bac0a80e
“ppt”: “shaken”
“verstat”: “TN-Validation-Passed”
}