UNLIMITED FREE
ACCESS
TO THE WORLD'S BEST IDEAS

SUBMIT
Already a GlobalSpec user? Log in.

This is embarrasing...

An error occurred while processing the form. Please try again in a few minutes.

Customize Your GlobalSpec Experience

Finish!
Privacy Policy

This is embarrasing...

An error occurred while processing the form. Please try again in a few minutes.

ATIS - 1000089

Study of Full Attestation Alternatives for Enterprises and Business Entities with Multi-Homing and Other Arrangements

active, Most Current
Organization: ATIS
Publication Date: 1 May 2021
Status: active
Page Count: 26
scope:

SHAKEN (ATIS-1000074-E, Errata to ATIS Standard, Signature-based Handling of Asserted information using toKENs) is defined as a framework that utilizes protocols defined in the IETF Secure Telephone Identity Revisited (STIR) Working Group that work together in an end-to-end architecture to provide traceability of calls to the OSP via a digital signature tied to a certificate identifying the OSP, and to allow the OSP to indicate whether or not a calling telephone number (calling TN) is valid. The cryptographic signature that protects this information allows the Terminating Service Provider (TSP) to verify the OSP identity and the integrity of the calling parameters, and to make decisions about how to handle the call based on the attestation information and other call parameters.

There are conditions where the OSP cannot fully attest that there is a known authenticated customer and/or that the customer associated with the calling TN is valid. This Technical Report will provide use cases where there may be a "knowledge gap" between the information the OSP can determine locally and the information it needs from outside parties or through additional methods to provide "full attestation" marking (attestation level "A"). In particular, it covers use cases where the authorizations might be determined through technical means and not necessarily ones that rely on policy decisions.

This document is focused on the SHAKEN attestation decision and does not address protection of other characteristics associated with calls or a calling party such as calling party name, intent of the call, or reputation of the caller.

This document is not intended to provide an exhaustive set of Use Cases covering every potential calling pattern that could require supplementary techniques beyond determining attestations with locally available information but nonetheless captures a broad representative sample of the scenarios where additional capability is needed for an OSP to determine TN authorization of calls involving Enterprises, Service Resellers, and other Business Entities. These Use Cases and flows are illustrative, and are not intended to provide a standard mechanism to determine the Attestation level. The capability of service providers, service and TN resellers, and other business entities to support one mechanism versus another to close the attestation knowledge gap will vary; thus, a suite of mechanisms is likely warranted. This document will capture the principles that should be adhered to in order to determine full attestation in the event there is no locally provisioned association available to the OSP regarding the customer and the use of a calling TN. Annex A in this report provides various solution mechanisms and associated impacts with each Use Case.

Purpose

Operating and business policies for the various users (Service Providers, Enterprises/Business Entities, and Resellers) of the Telecom Ecosystem are variable and situation driven. Oftentimes, the OSP cannot determine a verified association between the customer and the calling TN presented for customer calls based solely on internal assignments and local customer provisioning information.

In the SHAKEN framework, ATIS-1000074-E [Ref 1], Full Attestation is defined as follows:

A. Full Attestation:

The signing provider shall satisfy all of the following conditions:

• Is responsible for the origination of the call onto the IP based service provider voice 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.

NOTE 1: The signing provider is asserting that their customer can "legitimately" use the number that appears as the calling party (i.e., the Caller ID). The legitimacy of the telephone number(s) the originator of the call can use is subject to signer-specific policy, but could use mechanisms such as the following:

• The number was assigned to this customer by the signing service provider.

• This number is one of a range of numbers assigned to an enterprise or wholesale customer.

• The signing service provider has ascertained that the customer is authorized to use a number (e.g., by business agreement or evidence the customer has access to use the number). This includes numbers assigned by another service provider.

• The number is not permanently assigned to an individual customer but the signing provider can track the use of the number by a customer for certain calls or during a certain timeframe.

NOTE 2: Ultimately it is up to service provider policy to decide what constitutes "legitimate right to assert a telephone number" but the service provider's reputation may be directly dependent on how rigorous they have been in making this assertion.

This Report will define the principles for techniques that might provide additional input to allow the OSP to satisfy the third requirement (i.e., establishing a verified association with a TN) when making the SHAKEN attestation decision as well as identify the use cases where such techniques may be required to mitigate this attestation knowledge gap and identify the impacts with each of the different mechanisms.

Document History

1000089
May 1, 2021
Study of Full Attestation Alternatives for Enterprises and Business Entities with Multi-Homing and Other Arrangements
SHAKEN (ATIS-1000074-E, Errata to ATIS Standard, Signature-based Handling of Asserted information using toKENs) is defined as a framework that utilizes protocols defined in the IETF Secure Telephone...

References

Advertisement