Authentication Policies

Introduction

The Authentication Policies feature allows users to choose which phone calls should be authenticated using STIR/SHAKEN and how the authentication should be done. By default, calls are not authenticated.

The originating provider is responsible for attesting to each call leaving their network by determining which calls are made from legitimate calling numbers through the originating provider’s own criteria and then configuring their polices with the appropriate attestation level.

For call authentication, ClearIP generates a PASSporT token for a call which can be returned as an Identity header in a SIP 302 response or directly sent out-of-band to a call placement service.

Setup

Only outbound calls should be authenticated. Authentication policies can be applied to an Operator, SBC, service provider, group, user, calling SPID, and/or calling number.

Calling SPID

The Calling SPID refers to the porting corrected OCN. If your organization owns number blocks registered with their OCN, then you can create an authentication policy to sign all calls with a calling number registered to your OCN. If any numbers are ported out from your OCN, then calls from those numbers are automatically not authenticated using this policy. ClearIP directly access the NPAC database for number portability data, so you do not need to be manually update ClearIP with numbers ported in or out.

Method

ClearIP can perform call authentication in-band, out-of-band, or both in-band and out-of-band for a single call. Users can select the preferred method of authentication:

  • In-Band - ClearIP creates a PASSporT token containing a reference to the originating service provider’s certificate. The PASSporT token is returned in the SIP 302 response as a SIP Identity header. This SIP Identity header must be copied and inserted into the SIP Invite delivered to the terminating service provider. ClearIP can return the Identity header value in the SIP response as an Identity header, X-Identity header, or Identity header embedded in the Contact header. This is configurable per SBC in the SBCs page.

  • Out-of-Band - ClearIP creates a PASSporT token containing a reference to the originating service provider’s certificate. This PASSporT token is encrypted and delivered to the terminating service provider’s call placement service if it is listed in the Call Placement Services page. The call is routed to the terminating service provider over the voice network (TDM or IP). The delivery of the PASSporT token is independent of the call routing and does not impact the call signaling.

  • In-Band and Out-of-Band - ClearIP creates a PASSporT token which is both returned in the SIP 302 response as a SIP Identity header and is delivered to the terminating service provider’s call placement service.

Action

  • Ignore - Does not authenticate the call, but continues to route the call.
  • Attest - Authenticates the call with an attestation level of A, B, or C.
  • Block - Stops the call from being routed, returns a SIP 603 Decline.

Attestation level

Every PASSporT token created for an authenticated call includes an attestation level which is set by the originating service provider. The attestation level serves as an indication of how well the originating service provider trusts the calling party. It is a combination of familiarity with the customer making the call and the telephone number being asserted. There are three levels of attestation that an originating service provider can choose when authenticating a call:

  • Attestation Level A - Full Attestation: The originating service provider

    • Is responsible for the origination of the call onto the VoIP network.
    • Has a direct authenticated relationship with the customer and can identify the customer.
    • Has established a verified association with the telephone number used for the call.

    The originating service provider indicates that an identifiable caller is authorized to assert a calling number according to the service provider’s own policy. For example, calls from a subscriber using their registered phone number can be authenticated with attest A.

  • Attestation Level B - Partial Attestation: The originating service provider

    • Is responsible for the origination of the call onto the VoIP network.
    • Has a direct authenticated relationship with the customer and can identify the customer.
    • Has NOT established a verified association with the telephone number being used for the call.

The originating service provider cannot confirm that an identifiable caller is authorized to assert a calling number according to the service provider’s own policy. For example, a call comes from behind a PBX, and the originating service provider does not control phone number registration directly. The highest attestation level the originating service provider can authenticate the call with attest B.

  • Attestation Level C - Gateway Attestation: The originating service provider
    • Is the entry point of the call onto its VoIP network.
    • Has no relationship with the initiator of the call (e.g., international gateways).

For example, the originating service provider is a wholesale carrier that provides authentication and verification services to retail service providers. A call from a retail service provider’s subscriber can be authenticated by the wholesale carrier with attest C.

If the call is forwarded and the Diversion header is present in the SIP Invite, the attestation level is automatically set to C regardless of the attestation level selected in the Action. In the SIP Messages page, you can confirm whether the call has a Diversion header by checking whether the Forwarded field is set to Yes or No.

Origid

The PASSporT token includes an origid which is a unique value that is linked to the call source and can be used for traceback. The origid has the format of a universally unique identifier (UUID) like this example: c680da6e-4eb8-4a26-a49f-d9c2a021664e.

The origid can typically be generated by ClearIP, but customers also have the option to configure their network equipment to directly provide the desired origid values.

The Origination Identifier Algorithm field determines how ClearIP generates the origid. The default value for this field is Random, so that ClearIP generates a new origid for each phone call.

You also have the option to set the algorithm value to Automatic. If this is configured and the attestation level is A, then the origid is set to consistently be the ClearIP Operator ID. If the attestation level is B or C, then the origid is set to consistently be the ClearIP User ID.

User-supplied Attestation and Origid

By default, ClearIP assigns an Attestation level to a call based on the configured Action of the authentication policy and generates the Origid. Alternatively, users have an option to supply their own desired Attestation level by inserting a Attestation-Info header in the SIP Invite and setting the Use Attestation Info Header field to Yes.

Similarly, users can choose to supply their own desired Origid values by inserting the Origination-Id header with a valid UUID in the SIP Invite and setting the Use Origination Id Header field to Yes.

If the supplied Attestation-Info or Origination-Info values are invalid, then ClearIP will ignore the invalid Attestation-Info or Origination-Info headers, and assign the attestation level and origid based on the next best match configured authentication policy.

INVITE sip:14047884802@35.175.114.75:5060 SIP/2.0
Via: SIP/2.0/TLS sip.clearip.com:5061;branch=z9hG4bK6aa3.8d64dbe7693b511fc8419b773ad04ff8.0;i=4381e231;received=::ffff:10.0.11.122
Via: SIP/2.0/TCP 192.168.1.89:3000;received=18.208.235.205;branch=z9hG4bK-16593-1-0
From: "SIPp" <sip:14045266060@192.168.1.89:3000>;tag=1
To: "Test" <sip:14047884802@1.2.3.4:5060>
Contact:  <sip:14045266060@192.168.1.89:3000>
Call-ID: 1-16593@192.168.1.89
CSeq: 1 INVITE
Max-Forwards: 69
Attestation-Info: A
Origination-Id: 225eb849-bc03-41d6-9fe8-fe73a4e17837
Subject: Test
Content-Type: application/sdp
Content-Length: 0
X-Real-Ip: 18.208.235.205

Certificate

Calls must be authenticated using a specific certificate.

If your organization has been approved by the STI-PA, then you must have created a certificate in the Certificates page, so that you can select that certificate in this field.

If your organization has not yet been approved by the STI-PA, then you can authenticate calls using a TransNexus test certificate. Leave the Certificate field blank to automatically sign calls using the test certificate. Calls signed with the test certificate are limited to attestation level C regardless of the attestation level selected in the Action field.

Examples

Sign all calls with Attest A. The easiest way to authenticate your calls is to sign all calls with attest A regardless of the calling number. This can be done by leaving the Calling SPID and Calling Number fields blank to denote a wildcard entry. This can be used if it is impossible for any of your subscribers to spoof their calling number if, for instance, you operate a class 5 switch.

Sign all calls with Attest A Example

On-premises PBX Customer. A user called 1st National Bank is defined by their on-premises PBX IP address. From the authentication policies, all phone calls made from the 1st National Bank using their assigned phone numbers are automatically authenticated with attest A. The user has chosen to authenticate calls both in-band and out-of-band. Any calls coming from the 1st National Bank with a different calling number than the assigned numbers are signed with attest B.

On-premise PBX Customer Example

Sign list of trusted numbers. ClearIP can be used to only authenticate calls with a calling number that can be found in a list of trusted calling numbers. This list can be maintained by manually by users or automatically through the ClearIP API.

Authentication by Calling Numbers

Sign ranges of trusted numbers. Authentication policies can be configured for calls with a calling number within a trusted number range.

Authentication by Calling Number Range

Sign all numbers owned by a specific OCN. Authentication policies can be configured for calls with a calling number owned by a particular OCN. Authentication by Calling OCN

View authentication in SIP Messages

You can review the authentication results of signed calls by going to the SIP Messages page, clicking on the Columns button.

SIP Messages Columns Menu

When you select the STI Authentication option, ClearIP only displays column headers related to authentication:

  • STI Authentication Status - Whether the authentication was successful or not.
  • STI Authentication Attestation Indicator - The attestation level of a authenticated call that is sent.
  • STI Authentication Origination Identifier - The origid value of a authenticated call that is sent. The origid is a unique number associated with the call source.

SIP Messages STI Authentication

View SIP Identity header and token

To look at the SIP identity header created for a signed SIP invite sent previously, go to the SIP Messages page and locate the SIP message for the call in which you are interested. It may be helpful to filter calls by STI Authentication Status. Click on the blue Show button corresponding to the desired SIP message under the Show Message column.

Scroll down to find the SIP Response which looks like the image below. This is the response sent from ClearIP to the SBC. The SIP Identity header value is contained in the Identity header field in the SIP response. The switch or SBC must be configured to copy the Identity header and insert it into the redirected SIP Invite routed to the carrier.

SIP Response

SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/TLS sip.clearip.com:5061;branch=z9hG4bKfc9b.94e914e373099116acdc34462958bba0.0;i=5223e587;received=::ffff:10.0.11.245
Via: SIP/2.0/TCP 35.153.225.168;received=18.205.222.129;rport=42829;branch=z9hG4bK5H700Hre58t8B
To: <sip:+17187171131@sip.clearip.com;transport=tcp>;tag=a0e839c9-9202-44dd-91dd-9bc4f9cc38ba
From: <sip:+12013776051@35.153.225.168>;tag=t7Uc1rcy5aXHN
Call-ID: 4fd6078f-e977-1238-a5b5-124662f73474
CSeq: 18029679 INVITE
Identity: eyJhbGciOiJFUzI1NiIsInBwdCI6InNoYWtlbiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9jZXJ0aWZpY2F0ZXMuY2xlYXJpcC5jb20vNGE4NzFjMDYtZTBiNS00Y2I5LTgzNDctNDMxMjZiZDg2Yzg1LzNlMDRmZDRlZDAwMzJhYmJlY2ZjZmZiOWQwM2I3MzFkLmNydCJ9.eyJhdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6WyIxNzE4NzE3MTEzMSJdfSwiaWF0IjoxNTg1MTY2OTQyLCJvcmlnIjp7InRuIjoiMTIwMTM3NzYwNTEifSwib3JpZ2lkIjoiNGFlYzk0ZTItNTA4Yy00YzFjLTkwN2ItMzczN2JhYzBhODBlIn0.0U6T10zllPOc29GGCj6OIaPmPB-v-kybRzzZ-O6T0Qp1bRJacqAlKBSex4YcaBpR3TbLcswGK3fH56Zl8XYwcw;info=<https://certificates.clearip.com/4a871c06-e0b5-4cb9-8347-43126bd86c85/3e04fd4ed0032abbecfcffb9d03b731d.crt>;alg=ES256;ppt=shaken
Contact: <sip:17187171131@192.168.1.200;transport=tcp>;q=0.99
Reason: SIP;cause=302;text="no-fraud-detected"
Content-Length: 0

To decode the token contained in the Identity header, click on the STI Authentication Token tab. An example decoded token is shown below.

View decoded token

{
  "header": {
    "alg": "ES256",
    "ppt": "shaken",
    "typ": "passport",
    "x5u": "https://certificates.clearip.com/72bbb440-5ab0-42c1-ac9c-e7c1fe7c429f/0431844c46f94b878cd8a5b33ef18986.crt"
  },
  "payload": {
    "attest": "A",
    "dest": {
      "tn": [
        "17187171131"
      ]
    },
    "iat": 1585831546,
    "orig": {
      "tn": "12013776051"
    },
    "origid": "734bac90-c5de-4d62-be8f-3216e9b7ccf9"
  },
  "signature": "NSeWWKDQvnlNNoROcytoiMpQoSpQ1LW82qRt6Beb7MC0YKCS7hHYOGq3ll0mS24vLRyo60JB6VsoX5bDB8HUIQ"
}

The header contains general information about the format of the identity token and also includes a reference to the originating service provider’s certificate. This information is the same as that contained in the identity header.

The payload contains information about the call with most of it taken directly from the SIP invite.

The dest field contains the destination or called number. This is the value from the To header in the SIP Invite. In the SIP Messages page, this value is shown under the Asserted Called Number column.

The iat field represents the exact date and time that the identity token was created. Specifically, it represents the number of seconds that have elapsed since 00:00:00 UTC 1 January 1970.

The orig field contains the originating or calling number. This is the value from the P-asserted-identity header in the SIP Invite. If that is not available, the orig field copies the value in the From header. In the SIP Messages page, this value is shown under the Asserted Calling Number column.

The origid field is a unique number that can be associated with the call source. It can be used for trace back and allows one to create reputation profiles based on call sources.

SIP Response Identity Header Options

By default, ClearIP returns the token in the Identity header of a SIP 302 response.

SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/TLS sip.clearip.com:5061;branch=z9hG4bKb7a3.e4ee033fd0f85a5ca33b9c6cba8fba9e.0;i=dcde8c24;received=::ffff:10.0.14.91
Via: SIP/2.0/TCP 192.168.1.89:3000;received=18.208.235.205;branch=z9hG4bK-2670-1-0
To: <sip:14047884802@1.2.3.4:5060>;tag=22d113bc-92d0-4439-9162-c6b6e9500824
From: <sip:14045266060@192.168.1.89:3000>;tag=1
Call-ID: 1-2670@192.168.1.89
CSeq: 1 INVITE
Identity: eyJhbGciOiJFUzI1NiIsInBwdCI6InNoYWtlbiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9jZXJ0aWZpY2F0ZXMuY2xlYXJpcC5jb20vOGJlNmY0NWQtOTE5YS00N2JiLTk2MWUtNzBjMTIxZjUyYWMxL2MxZDNlN2RhMzg4NmE5Mzk0OTgwYjYxOTA5OGNmOTE4LmNydCJ9.eyJhdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6WyIxNDA0Nzg4NDgwMiJdfSwiaWF0IjoxNTk5ODc2OTg0LCJvcmlnIjp7InRuIjoiMTQwNDUyNjYwNjAifSwib3JpZ2lkIjoiYmY3ODNkY2QtNzhjZi00OWI3LWI3NWYtZmZhNGMyYzdkYWY2In0.qrjOEWm4PX9Y0q_DhHgo7KGZ5dWgfUMlA84WGaGCpHecnfjIXPGRtKpA3MYSgztqsf-jj8nSOsCpLeI8EaXVug;info=<https://certificates.clearip.com/8be6f45d-919a-47bb-961e-70c121f52ac1/c1d3e7da3886a9394980b619098cf918.crt>;alg=ES256;ppt=shaken
Contact: <sip:14047884802@1.2.3.4:5060>;q=0.99
Reason: SIP;cause=302;text="no-fraud-detected"
Content-Length: 0

ClearIP can be configured to return the token value in an alternative header if configured in the SBCs page under the Identity Header field:

  • X-Identity
X-Identity: eyJhbGciOiJFUzI1NiIsInBwdCI6InNoYWtlbiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9jZXJ0aWZpY2F0ZXMuY2xlYXJpcC5jb20vOGJlNmY0NWQtOTE5YS00N2JiLTk2MWUtNzBjMTIxZjUyYWMxL2MxZDNlN2RhMzg4NmE5Mzk0OTgwYjYxOTA5OGNmOTE4LmNydCJ9.eyJhdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6WyIxNDA0Nzg4NDgwMiJdfSwiaWF0IjoxNTk5ODc3MDMxLCJvcmlnIjp7InRuIjoiMTQwNDUyNjYwNjAifSwib3JpZ2lkIjoiYmY3ODNkY2QtNzhjZi00OWI3LWI3NWYtZmZhNGMyYzdkYWY2In0.IHgPznwooMq7EXxkqlSWvp70CZ_TvfcPD5804OmATYAjs3Y6tZjYzrh7GO1LLPBa4LGNyNxgmGqI2jeiBxOUdQ;info=<https://certificates.clearip.com/8be6f45d-919a-47bb-961e-70c121f52ac1/c1d3e7da3886a9394980b619098cf918.crt>;alg=ES256;ppt=shaken
  • Identity Embedded in Contact
Contact: <sip:14047884802@1.2.3.4:5060>;q=0.99?Identity=eyJhbGciOiJFUzI1NiIsInBwdCI6InNoYWtlbiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9jZXJ0aWZpY2F0ZXMuY2xlYXJpcC5jb20vOGJlNmY0NWQtOTE5YS00N2JiLTk2MWUtNzBjMTIxZjUyYWMxL2MxZDNlN2RhMzg4NmE5Mzk0OTgwYjYxOTA5OGNmOTE4LmNydCJ9.eyJhdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6WyIxNDA0Nzg4NDgwMiJdfSwiaWF0IjoxNTk5ODc3MTAyLCJvcmlnIjp7InRuIjoiMTQwNDUyNjYwNjAifSwib3JpZ2lkIjoiYmY3ODNkY2QtNzhjZi00OWI3LWI3NWYtZmZhNGMyYzdkYWY2In0.Eze0w6pKGAKh1uyszr9WdivTxdOe9hp1PGLQbX2iZoXuXRAhVTNR7iBS0nWUXzItBLdTklWDEqg3m3EQIp3aig%3Binfo%3D%3Chttps%3A%2F%2Fcertificates.clearip.com%2F8be6f45d-919a-47bb-961e-70c121f52ac1%2Fc1d3e7da3886a9394980b619098cf918.crt%3E%3Balg%3DES256%3Bppt%3Dshaken
  • Identity Embedded in Contact URI
Contact: <sip:14047884802@1.2.3.4:5060?Identity=eyJhbGciOiJFUzI1NiIsInBwdCI6InNoYWtlbiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9jZXJ0aWZpY2F0ZXMuY2xlYXJpcC5jb20vOGJlNmY0NWQtOTE5YS00N2JiLTk2MWUtNzBjMTIxZjUyYWMxL2MxZDNlN2RhMzg4NmE5Mzk0OTgwYjYxOTA5OGNmOTE4LmNydCJ9.eyJhdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6WyIxNDA0Nzg4NDgwMiJdfSwiaWF0IjoxNTk5ODc3MDc1LCJvcmlnIjp7InRuIjoiMTQwNDUyNjYwNjAifSwib3JpZ2lkIjoiYmY3ODNkY2QtNzhjZi00OWI3LWI3NWYtZmZhNGMyYzdkYWY2In0.i5c7DOwRTvRp-FKvtYBM6HRgWOgV5fnw3FCg3D-UivlgaCXoXpLN4Z_rdWu7EBlzamltAusb3t-dnWRZ41-p4A%3Binfo%3D%3Chttps%3A%2F%2Fcertificates.clearip.com%2F8be6f45d-919a-47bb-961e-70c121f52ac1%2Fc1d3e7da3886a9394980b619098cf918.crt%3E%3Balg%3DES256%3Bppt%3Dshaken>;q=0.99

SIP Invite containing Identity header

The SBC must be configured to copy the Identity header from the SIP 302 response and insert it into the SIP Invite sent to the termination carrier. In the call trace, you should confirm whether your SBC is inserting the Identity header into the outgoing SIP Invite.

Here is an example SIP Invite containing the Identity header which is sent to a termination carrier.

INVITE sip:18038371753@2.2.2.2 SIP/2.0
Via: SIP/2.0/UDP 1.1.1.1:5060;branch=z9hG4bKEC001QwRn3bWxAmK00054B
Accept-Language: en
Call-ID: 20210525181701061349-fdfb330c3636fe678da0ef730a5daae7
Contact: <sip:8039373338@1.1.1.1:5060;transport=udp>
CSeq: 201 INVITE
From: <sip:18039373338@1.1.1.1>;tag=LgTdPYBHBRDUcv2S00054A
Max-Forwards: 20
To: <sip:18038371753@2.2.2.2>
Date: Tue, 25 May 2021 18:17:01 GMT
Server: NetSapiens SiPBx v41-2-4
Identity: eyJhbGciOiJFUzI1NiIsInBwdCI6InNoYWtlbiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9jZXJ0aWZpY2F0ZXMuY2xlYXJpcC5jb20vdHJhbnNuZXh1cy9jM2E5ODQ5MGFjNzIxNmYzOGI5ZWE4ZmRmMjNmN2VkMy5jcnQifQ.eyJhdHRlc3QiOiJDIiwiZGVzdCI6eyJ0biI6WyIxODAzODM3MTc1MyJdfSwiaWF0IjoxNjIxOTY2NjIxLCJvcmlnIjp7InRuIjoiMTgwMzkzNzMzMzgifSwib3JpZ2lkIjoiMDVjNjkwYWQtNTM3OC00MjdmLWFjNzgtMTkxOGUxZWU3YjU5In0.CgumLyyBzKZ7T2UQxSC5bAexHY1qlWDD6xXGPH3ztVv5uECbFPYEs3T9QilPwsROB0jaCHxQYH-GVBeXNgAw5Q;info=<https://certificates.clearip.com/transnexus/c3a98490ac7216f38b9ea8fdf23f7ed3.crt>;alg=ES256;ppt=shaken
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, PRACK, SUBSCRIBE, INFO, PUBLISH
Allow-Events: talk, hold, conference, LocalModeStatus
Content-Type: application/sdp
Content-Length: 262

v=0
o=NetSapiens_Nms 1621966621 1621966621033 IN IP4 72.1.48.202
s=SIP Call
c=IN IP4 72.1.48.202
t=0 0
m=audio 27808 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=silenceSupp:off - - - -
a=fmtp:101 0-15
a=ptime:20
a=sendrecv